Aside state persisted in query params

[theosiemensrhodes]

Summary

Aside (detail panel) state is now persisted in the URL via query parameters. Opening an aside updates the URL, and refreshing the page or sharing the link reopens the same aside.

What changed

Controlled PageLayout

PageLayout now supports an optional Radix-style controlled pattern with open / onOpenChange props. When provided, the aside open/close state is driven externally. Pages without asides are unaffected.

Classes page (?classId=)

Clicking a class adds ?classId=xxx to the URL. On load, if the param is present, the aside opens and the correct term is automatically selected.

Schedule page (?shiftId=)

Clicking a shift adds ?shiftId=xxx to the URL. On load, the aside opens and the view navigates to the shift's month so it appears in the list/calendar.

Coverage page (?coverageId=)

Clicking a coverage request adds ?coverageId=xxx to the URL. A new coverage.byId backend route was added so the aside can fetch its data independently (previously it read from the in-memory list). Next/prev navigation updates the URL param accordingly.

Calendar view fix

The calendar view now respects selectedDate on initial render, fixing an issue where switching from list to week view would reset the visible date.

[greptile-apps]

Greptile Summary

This PR persists aside/detail-panel state in the URL via nuqs query parameters across the Classes, Schedule, and Coverage pages, enabling deep-linking and page refresh survival. The core approach — a controlled open/onOpenChange pattern on PageLayout, individual byId queries for fetching detail data, and lifting selected-item IDs into URL state — is well-structured and consistent across all three pages.

Key issues found:

• Security (coverage-router.ts): The new coverage.byId tRPC route does not apply the row-level visibility filters enforced by the list route. Non-admin users (those without shifts: view-all) are normally restricted in the list to open requests and requests they're personally involved in. The byId route bypasses this entirely, allowing any authenticated user with coverage: view to fetch any coverage request by ID — a concern made more acute because URL sharing is the specific feature being introduced.
• Type safety (coverage-aside.tsx): An unsafe type cast as CoverageListItem | undefined may hide server/client type mismatches (e.g., date serialization differences) and should be removed.
• React pattern violation (class-list-view.tsx): A side effect (setQueryTerm) is called inside a setState updater function, which violates React's purity requirement and can cause double mutations in Strict Mode.

Confidence Score: 2/5

• The security issue in coverage.byId bypass requires remediation before merge; the other issues are lower severity but should be fixed.
• The byId endpoint's lack of row-level visibility filtering is a meaningful security gap given that URL sharing is the exact scenario this PR enables. Non-admin users can bypass list visibility rules by directly accessing coverage IDs. The side effect in the class-list-view updater and unsafe type cast in coverage-aside are lower-severity issues but represent real violations of React best practices and type safety.
• src/server/api/routers/coverage-router.ts requires the most attention due to the missing visibility filter on the byId route.

_{Last reviewed commit: 45463e4}

[theosiemensrhodes]

@greptile re-review