Convert remaining unconditional useQuery call sites to useSuspenseQuery

[chiptus]

Context

Follow-up from a broader useQuery audit during PR #107 review. Four hooks are called unconditionally (no real enabled: gating, no deliberate inline error/loading UI) for data that's either already prefetched by a route loader, or easily could be — good candidates for the loader-prefetch + useSuspenseQuery pattern used elsewhere in this codebase.

Candidates

1. useGroupMembersQuery (src/api/groups/useGroupMembers.ts, called from useSetFiltering.ts) — already prefetched by the group route loader (groups/$groupSlug.tsx).
2. useUserGroupsQuery (src/api/groups/useUserGroups.ts, called from SetGroupVoting.tsx) — same data the /groups/ route loader already prefetches via userGroupsQuery; this call site duplicates it without Suspense.
3. useFestivalsQuery (src/api/festivals/useFestivals.ts, called from FestivalSelection.tsx) — core content of the festival-selection page, unconditionally required; no loader currently prefetches it (would need one added).
4. useGenresQuery (src/api/genres/useGenres.ts, called from GenreBadge and AddArtistDialog) — already prefetched by the sets route loader (sets/index.tsx); these call sites duplicate it.

Out of scope here

useStageQuery per-item flicker — tracked separately in #108.

Confirmed NOT candidates (checked, correctly plain useQuery): vote queries, invite validation, custom links, profile/permissions, duplicate-artists, admin roles, soundcloud playlist, analytics table — all have genuine enabled: conditions or deliberately show inline error/loading UI instead of throwing to Suspense.

Bonus finding — separate cleanup, not part of this issue

9 wrapper hooks appear to be dead code (never called anywhere; everything already reads their queryOptions factory directly via ensureQueryData/useSuspenseQuery): useSetBySlugQuery, useGroupInvitesQuery, useGroupBySlugQuery, useGroupDetailQuery, useFestivalQuery, useFestivalEditionQuery, useArtistQuery, useArtistBySlugQuery, useArtistNotesQuery. Worth a human check to confirm truly unused before deleting — tracked in #109.

Flagged during PR #107 review, not fixed there to keep that PR scoped to the loader-await change.

[chiptus]

Correction: the dead-hook cleanup mentioned above is tracked separately in #110, not this issue.

---

Generated by Claude Code

[chiptus]

This was generated by AI during triage.

Triage Notes

What we've established so far:

• Traced all four candidates against the current routes and loaders. The core premise — "already prefetched by a route loader, good candidate for the loader-prefetch + useSuspenseQuery pattern" — only holds cleanly for one of the four:
  • useFestivalsQuery (FestivalSelection) — issue already correctly notes no loader prefetches this today; a loader would need to be added. No correction needed here.
  • useGenresQuery — only partially covered. The sets/index route (which renders ArtistsTab → SetMetadata → GenreBadge) does prefetch genresQuery(). But GenreBadge is also rendered from the sets/$setSlug route (SetInfoCard, MultiArtistSetInfoCard, IndividualArtistCard) and from three admin pages (AddArtistDialog, GenresCell, plus other ArtistsManagement components) — none of those routes prefetch genres today.
  • useGroupMembersQuery (useSetFiltering, called from the sets/index route) — the group ID here comes from a filter-dropdown value on the sets/artists page, not from visiting a specific group's page. The groups/$groupSlug.tsx loader this issue points to prefetches a completely different route. This call site has no existing prefetch coverage at all.
  • useUserGroupsQuery (called from SetGroupVoting on sets/$setSlug, and GroupFilterDropdown on sets/index) — same issue. The /groups/ route loader prefetches userGroupsQuery(userId, { all: false }), but only when a user actually lands on /groups/ first, which isn't guaranteed before hitting either of these call sites. No existing coverage.
• Net effect: for the two group-related candidates, and for two of useGenresQuery's call sites, converting to useSuspenseQuery isn't a same-behavior mechanical swap — it requires adding a prefetch to a different route loader than the one named, and deciding what should happen while that prefetch is in flight.
• One of those decisions has real UX weight: the group filter dropdown (useGroupMembersQuery, GroupFilterDropdown) is optional and user-triggered, not core page content. Suspending the whole sets/index view while a user's group membership loads (the first time they pick a group filter) would be a visible behavior change, not just an invisible flicker fix like Fix stage-badge flicker: derive per-set stage from prefetched edition list #108.

What we still need from you (@reporter):

• For useGroupMembersQuery and useUserGroupsQuery: which route(s) should actually gain the prefetch — is it worth adding to sets/index/sets/$setSlug loaders, or should these stay as plain useQuery since the data isn't guaranteed to be needed on every page load?
• For the group filter dropdown specifically: is it acceptable for selecting a group filter to suspend part of the page on first use, or should that stay a non-Suspense loading state?
• For useGenresQuery: should the fix also add a genres prefetch to sets/$setSlug and the admin routes, or is this issue meant to cover only the ArtistsTab/sets/index site (where the existing prefetch already lines up)?

---

Generated by Claude Code

[chiptus]

Flagged again during review of #112 (both FestivalSelection.tsx and admin's FestivalManagementTable.tsx still on plain useQuery/isLoading/isError). Candidate 3 above already covers FestivalSelection.tsx; adding FestivalManagementTable.tsx (useFestivalsQuery({ all: true }), src/pages/admin/festivals/FestivalManagementTable.tsx) as the same pattern — unconditionally required, no loader prefetching it yet.

---

Generated by Claude Code