[jhodapp]

Description

Frontend half of the series daylight saving fix. Monthly series can no longer start on the 29th, 30th or 31st, which the backend now rejects. The manual test plan gains daylight saving cases.

Pairs with refactor-group/refactor-platform-rs#455.

Changes

• validateRecurrence returns "Monthly sessions can't start on the 29th, 30th or 31st. Pick the 28th or earlier." when the first session's local day is after the 28th. The create form and the reschedule-series dialog both use it, so submit stays disabled.
• The day is judged in the user's timezone, not UTC. A 7 PM Chicago session on the 28th is allowed.
• docs/test-plans/resend_calendar_invite_manual_testing.md: Part D (D1–D6) covers series across a daylight saving change, checked in Google Calendar. Cleanup now deletes through the dashboard, so cancellations are checked too.

Screenshots / Videos Showing UI Changes (if applicable)

Helpful: the create dialog with Monthly on the 30th, showing the message and the disabled button.

Testing Strategy

• npm run test: 2207 pass. New recurrence.test.ts cases cover days 29–31, the 28th, weekly/daily on the 31st, and local versus UTC day (Chicago and Tokyo). Switching the check to the UTC day fails them.
• Part D was run live against rs#455 with a Chicago coach. All six cases passed in the app and in Google Calendar.

Concerns

None. No wire change.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge.

Summary

Adds a shared check that blocks monthly series starting after the 28th in the user's timezone.

• Monthly series now require their first session to fall by the 28th.
• The manual calendar plan now checks series across daylight-saving changes.

No actionable issues found. Review was based on source inspection; tests were not run.

_{Reviews (1) · Last reviewed commit: "docs(test-plans): daylight saving cases ..." · Reviewed by Greptile}