Test design: fixed-TZ assertion to catch symmetric TZ mutations

[kiki830621]

Problem

testUntilDateUsesEndOfDay 是 round-trip 一致性 test：producer (parseUntilDate) 和 consumer (Calendar.current.dateComponents) 都用 Calendar.current。這代表它只能抓 asymmetric TZ regressions——例如 producer 改用 UTC 但 consumer 仍用 local（或反之）。

From verification of #15 by devils-advocate (HIGH):
「TZ assertion 是 round-trip 一致性 test：producer 寫什麼，consumer 讀什麼。它無法抓『producer 邏輯本身錯了』的 bug，只能抓『producer 和 test environment 的 TZ 不一致』的 bug。」

漏網的 mutation 範例

如果有人同時把 producer 和 consumer 都從 Calendar.current 改成 Calendar(identifier: .gregorian) (預設 UTC)，當前 test 仍 pass。但實務 production 下，parseUntilDate 產生的 Date 對 Taipei 用戶會變成隔天 07:59:59，until_date 過濾漏掉一整天的訊息。

Type

enhancement

Expected

新增 fixed-TZ test 鎖死 producer 的絕對行為（不依賴 Calendar.current）：

func testUntilDateInFixedUTCAsserts() {
    var cal = Calendar(identifier: .gregorian)
    cal.timeZone = TimeZone(identifier: "UTC")!
    let parsed = try! parseGetChatHistoryArgs([
        "chat_id": .int(100),
        "until_date": .string("2026-04-17"),
    ])
    let utcComponents = cal.dateComponents(
        [.year, .month, .day, .hour],
        from: parsed.untilDate!
    )
    // Assert producer 的絕對 TZ 行為，不依賴 test environment
    // 例: 如果 producer 用 local TZ + Asia/Taipei，UTC = 2026-04-17 15:59:59
    //     hour=15 ≠ Calendar.current 抽出的 23
}

需要決定：

• 預期 producer 是什麼 TZ 行為（local vs UTC vs configurable）？
• 如果是 local，test 環境如何 lock TZ（CI 跨平台跑會在不同 TZ）？

Code Reference

• Sources/CheTelegramAllMCPCore/DateParsing.swift:58-67 (parseUntilDate)
• Tests/CheTelegramAllMCPTests/ServerHandlerLogicTests.swift:96-122 (現有 round-trip test)

Related: #15