fix: batch room meeting status queries via prop-drilling

[deardarlingoose]

Summary

Alternative to #848 (batcher approach): prop-drilling version that achieves the same N+1 → 1 query reduction without @yornaath/batshit dependency.

• Backend: Same POST /v1/rooms/meetings/bulk-status endpoint + bulk DB methods (get_by_names, get_all_active_for_rooms, get_upcoming_for_rooms)
• Frontend: Parent (RoomList) fetches all room statuses via useRoomsBulkMeetingStatus(roomNames) hook, passes data down as props to RoomTable → MeetingStatus
• CI: Fix pnpm 8→10 auto-detect, add concurrency group, dedupe setup-node
• Tests: Jest + jsdom + testing-library, 3 tests for bulk hook

Prop-drilling vs Batcher trade-offs

Aspect	#848 (Batcher)	This PR (Prop-drilling)
Data ownership	Per-component (each MeetingStatus owns its query)	Parent (RoomList owns all meeting data)
Batching	@yornaath/batshit DataLoader with 10ms window	None needed — single useQuery call
New dependency	@yornaath/batshit	None
Extra module	meetingStatusBatcher.ts	None
Query key	Per-room keys via $api.queryOptions	Single ["bulk-meeting-status", roomNames]
Cache granularity	Per-room invalidation	Coarser (entire list)
Reuse in other contexts	Each card self-contained	Parent must re-implement bulk fetch

Test plan

• CI workflow runs (triggers on www/** changes)
• Rooms page loads with single bulk POST (verify in network tab)
• Individual room pages still work (MeetingSelection.tsx unchanged, uses per-room hook)
• Meeting create/deactivate invalidates bulk status cache