Booking page crashes with "RangeError: Invalid time value" on invalid ?month= or ?date= query params #30302

Issue Summary

The Booker reads ?month= and ?date= from the URL without validating them. A malformed value makes the whole booking page crash with the generic "It's not you, it's us" error page. Other odd values are accepted silently and lead to confusing states: months in the past, months that roll over (2026-13 shows January 2027), and absurd years (99999-01 shows September 9999).

These params appear in shareable/booking links and are easy to get wrong (hand-edited links, truncated URLs, broken integrations that build links), so a bad link currently dead-ends the booker instead of falling back to a sensible default.

Steps to Reproduce

1. Open any public booking page with an invalid param, e.g. http://localhost:3000/pro/30min?layout=month_view&month=garbage.
2. Or .../pro/30min?layout=month_view&date=garbage.

Results observed on a local dev instance (seeded pro user, event 30min, today = 2026-10-06):

Actual Results

• Invalid values crash the page. Console: RangeError: Invalid time value at Date.toISOString in useTimesForSchedule (packages/features/schedules/hooks/useTimesForSchedule.ts, the monthDayjs.startOf("month").toISOString() calls around lines 117-124).
• Past, overflowing and extreme values are accepted as-is into the Booker store; the URL is not rewritten.

Expected Results

• An invalid or unparseable month/date never crashes the page; the Booker falls back to the current month (and rewrites the URL to match).
• Past months/dates fall back to the current month, since they can't be reached through the UI.
• Values like 2026-13 or 2026-02-31 are treated as invalid, not silently rolled over.

Technical details

• The values enter through the Booker store initial state: packages/features/bookings/Booker/store.ts (month: initializer reading getQueryParam("month"), around lines 520-525, and selectedDate: getQueryParam("date"), around line 457). Neither is validated.
• Suggested fix: validate with strict dayjs parsing (YYYY-MM / YYYY-MM-DD with strict = true) and clamp to >= current month in one small helper used by both initializers, with unit tests (Vitest, TZ=UTC). No UI or translation changes needed.
• Open question for maintainers: for event types with an unlimited booking period, should there be an upper bound on how far ahead ?month= may point (e.g. 12 or 24 months)? Every month triggers a full slots computation, so an arbitrary far-future month is a cheap way to make the server do work. I'd rather ask than assume, and I would not add a bound in the first PR unless asked.
• I considered a "polite modal" for out-of-range dates, but a silent fallback needs no new UI or strings and keeps the change small. Happy to do the modal instead if maintainers prefer.
• I searched existing issues and PRs and found nothing about validating these params. Closest: merged fix: booker atom not resetting month query param #14715, fix: Ensure previous slots do appear if the month search param is removed  #18097, feat: prevent automatic query parameters when opening booking page #18132, and closed fix: Ensure correct fallback to current month when 'month' query param is … #18096, which touched month param handling but not validation.
• I'm happy to open a PR for this.
• Environment: Cal.diy main at 54343aa, local dev server (Next 16), Chrome, macOS. Not verified on a production build.

Evidence