fix: reject nonexistent calendar dates before review or dispatch

[wangtaotaotao95]

Calendar drafts such as 2026-02-29 or 2026-04-31 pass the current shape checks because Date.parse normalizes them into the following month. Invalid dates can consequently pass proposal validation and reach Google create/update calls.

Validate the calendar-date component with the existing Zod ISO date validator, while retaining chronological ordering, explicit offsets, named-zone validation, and the existing timed formats (including minute precision). Regression tests cover invalid start/end dates, leap-year boundaries, valid dates and offsets, and rejection before any Google request.

Validation: before the fix, two regressions failed (35/37 focused tests passed). After the fix, focused tests pass 37/37 and the full suite passes 202/202. Lint, root/mobile/worker typechecks, server build, and web/iOS/Android bundle exports pass on Node 24. Google was tested with fixtures, not a live account; native device runs and Docker container suites were not run locally.

[jerelvelarde]

Useful calendar integrity fix: reject nonexistent calendar dates before proposal/provider dispatch while retaining minute precision, explicit offsets and leap-day behavior. All 37 focused domain/Google tests pass locally, including zero Google requests for invalid create/update dates. Description covers checks and integration limits. No actionable correctness or security findings. Merge only after updated-head CI passes.

[jerelvelarde]

Re-reviewed the current-main update: the PR's fix and its regression tests remain unchanged in scope, and recently merged behavior/tests are retained. No new actionable findings. Approval applies to this updated head; merge after all seven required CI checks pass.