DST fall-back boundary tests for parseUntilDate / validateDateRange (fixed TimeZone)

[kiki830621]

Problem

From verification of #9/#10/#14 by devils-advocate (INFO) + inherited from #15/#19:
「testSinceEqualsUntilSameDayAccepted 跑在 Calendar.current / TimeZone.current。在 CI（UTC）跑沒事。但若使用者位於 America/New_York，2026-11-01 是 DST fall-back day（25 hours）：

• since = 2026-11-01 00:00:00 EDT
• until = parseUntilDate → wall-clock 23:59:59 → 2026-11-01 23:59:59 EST
• 跨越 DST 邊界，但 timeIntervalSince1970 仍然 since < until，所以 test pass

這是 #15/#19 inherited gap：「TZ symmetric mutation gap」。Batch 4 沒製造新 gap，只是繼承了既有 gap。」
— Source: team:devils-advocate (INFO)

延續 #16 / #19 family — parseISODate / parseUntilDate / validateDateRange 在 DST fall-back day（25-hour day）的行為應有專屬 fixed-TimeZone test 覆蓋。

Type

enhancement (test coverage)

Expected

新增 DST 專屬 tests with TimeZone(identifier: "America/New_York") fixed:

• testParseUntilDateOnDSTFallbackDay: 2026-11-01 → 23:59:59 EST (after DST switch), not 22:59:59
• testValidateDateRangeAcrossDST: since=2026-11-01 00:00 EDT, until=2026-11-01 23:59:59 EST → still passes (since < until despite DST)
• testSinceUntilSameDayBoundsExactlyAcrossDST: 用同一日期 string 構造的 since/until 在 DST 日仍滿足 validateDateRange

採用 fixed TimeZone(identifier:) 而非 Calendar.current，避免依賴 CI 時區。

Acceptance

• 3 個 fixed-TZ tests covering DST fall-back semantics
• Tests use TimeZone(identifier: "America/New_York") and TimeZone(identifier: "Australia/Sydney") (DST spring-forward direction)
• CI passes regardless of host TZ

Code Reference

• Sources/TelegramAllLib/DateParsing.swift:69-74 (wall-clock construction with DST note)
• Tests/CheTelegramAllMCPTests/DateParsingTests.swift (existing DST test infrastructure)
• Tests/CheTelegramAllMCPTests/ServerHandlerLogicTests.swift (validateDateRange tests — should also gain DST coverage)

Related: #15, #16, #19, #10