[jhodapp]

Description

The Join session menu and the New session dialog asked /nearest once per person a coach works with, so a coach with 20 people sent 20 requests each time either one loaded. They now send one request per 50 people, using the batched form of /nearest agreed with the backend: contract coaching_sessions_nearest_window v4 (decision coaching_sessions_nearest_window_v4_agreed, backend rs#466).

GitHub Issue: none (follow-up from #527)

Changes

• /nearest requests: NearestWindow.relationshipId becomes relationshipIds, sent as coaching_relationship_ids (comma-separated). Nothing sends the old single coaching_relationship_id any more, so the backend can retire it.
• useNearestEachCoachingSessions: splits the ids into groups of 50 (NEAREST_MAX_RELATIONSHIPS), sends one request per group with one session either side of now, and merges the results. If any group fails, the whole read fails. With no relationships, no request is sent.
• Join session menu: its single-person read on a session page sends a one-id list.
• Tests:
  • A new spec, coaching-sessions-nearest-batched.test.tsx, covers:
    • one request for 3 people;
    • two requests (50 + 1) for 51 people, with the results merged;
    • a failed group failing the whole read;
    • no request with no relationships;
    • the one-id read.
  • The existing nearest and Join session menu tests are updated to the new shape.

Testing Strategy

• npx vitest run, npx tsc --noEmit.
• Live, once rs#466 is running: open the Join session menu and the New session dialog.
  • Each should send one /nearest request carrying every relationship id, and show the same people and sessions as before.
  • A session page's Join session menu should send one id, with before=2&after=3.

Live verification (against rs#466's branch, local Postgres)

• Join session menu: one /nearest request carrying all 9 relationship ids, sent only once the menu opens. The carousel order, inactive count and "Last …" labels match the DB. The menu also passes design-system test plan cases G2, G3, G6 (all three windows), G7, G10, G14 and G15.
• New session dialog (Reschedule this and following sessions, and fold Edit series into the dialog #527 with this commit on top): one request for all 8 people. The Who order, sub-lines and When prefill are unchanged. With /nearest returning 500, it falls back to name order as before.
• Direct wire checks:
  • per-relationship windows, and ids that contribute nothing;
  • exactly at around counts as after;
  • include=relationship;
  • every 400, and the 50-id cap.

Concerns

• Merge after rs#466: against today's main backend, /nearest rejects requests that don't have coaching_relationship_id.
• The New session dialog in Reschedule this and following sessions, and fold Edit series into the dialog #527 uses the same hook, so it picks this up with no further change once both PRs are merged.