Make the availability picker usable on mobile

[chpy04]

Changes

The availability grid (EditAvailability) was built for the 700px-wide desktop modal, and on a phone it was close to unusable:

• the table's minWidth: 700 forced horizontal scrolling to reach the later days of the week
• the percentage row heights (calc((100% - 50px) / 12)) collapse to ~18px tall slots once the grid renders as a page instead of inside the fixed-height dialog
• "Fill from busy times" and "Invert Availability" were squeezed onto one line
• the fixed CANCEL/SAVE bar sat directly on top of the last row of slots
• drag-to-paint is the only bulk-fill affordance, and it does not exist on touch

What this changes:

• Fits the week to the viewport on phones instead of scrolling sideways — narrower day/time label column, abbreviated day names, smaller type, and a fixed 36px row height so slots stay tappable.
• Stacks the two grid controls above the grid on narrow screens.
• Slot drag handlers move from mousedown/mouseup to pointerdown/pointerup so a tap registers directly rather than through emulated mouse events. Drag-to-paint stays mouse-only (setIsDragging(event.pointerType === 'mouse')) — see Notes.
• Day-header and time-label toggles fill or clear a whole column or row. This is the touch replacement for click-and-drag; it works on desktop too, surfaced by the pointer cursor and a tooltip.
• Mobile action bar gets a border, a safe-area inset, and matching bottom padding on the grid so it stops covering slots; the long "Update your availability for…" header no longer renders at the 30px page-title size.
• Same fit-to-width treatment for the read-only SingleAvailabilityView.
• The event availability page stacks its grid and member panel on mobile rather than squeezing the panel into a 180px column.

Small cleanup along the way: the "write the map, then recompute the displayed week" block was repeated in three places and is now a single commitAvailabilities helper.

Notes

Desktop is deliberately untouched. Every style change is gated behind the existing max-width:480px check that this component already used, and the mobile-only values are applied with conditional spreads so desktop gets no declaration at all rather than one that restates a default. Verified by measurement and pixel diff — see Test Cases.

Why drag-to-paint is still mouse-only. Making it work on touch requires touch-action: none on the slots, which would stop the page from scrolling anywhere over a 12-row grid. The day/time label toggles cover the same need (fill a day, fill an hour across the week) without taking scrolling away.

The Fill from busy times and Invert Availability bulk actions are unchanged.

Test Cases

Verified in Chromium against the real components:

• Desktop parity, 1440px and 1024px, edit modal and read-only modal: dialog size, day-header box, time-column width, slot size and header font/line-height all identical to the pre-change values. Three of the four screenshots are byte-identical to the pre-change render; the fourth differs only over the Fill from busy times button, and two runs of identical code produce the same diff there — it is the busyTimesIsFetching disabled-state flicker, not this change.
• Desktop mouse drag-paint still works: dragging down 5 cells in a column and across 4 cells in a row toggles exactly those cells.
• Touch: one tap toggles exactly one slot (no double-fire from emulated events); tapping a day header fills all 12 slots and tapping it again clears them; tapping a time label fills that hour across days when partially filled.
• No horizontal page overflow at 320 / 390 / 430 / 480px. Slots measure 38×35px at the 320px worst case.
• tsc --noEmit clean, prettier --check clean, yarn build passes.
• yarn lint could not be run in this environment — ESLint 7 crashes on Node 22 here (async-function/require.mjs ESM error), unrelated to this diff. Worth a look on CI.

Screenshots

I can't attach images from the environment this was written in, so the measurements above stand in for them — the desktop renders are pixel-compared against develop rather than eyeballed. Happy for a reviewer to grab the two required screenshots (normal window / smallest window) before merge, or I can describe exact repro steps.

To Do

• Attach the normal-window and smallest-window screenshots the template asks for
• Link the ticket number (I don't have one for this)

Closes # (issue #)

---

Generated by Claude Code