explore: a Group membership resolver + splitting useUserGroups' boolean flag

[chiptus]

Problem

Two structural issues in src/api/groups/:

1. useUserGroups.ts (137 lines) hides a wide behaviour swing behind one boolean: fetchUserGroups(userId, { all }) flips the auth model (admin-gated) and the is_member semantics (line 55), a shallow interface over a branchy implementation. It also fires an N+1 count query per Group (addMemberCounts, lines 44-59).
2. The "resolve profiles for a set of member ids" join is hand-stitched in at least three modules — useGroupVotes.ts (members → votes → profiles), useInviteToGroup.ts (members → profiles), useGroupMembers.ts — each re-deciding error handling (in useGroupVotes a profiles failure is swallowed with username: null).

No tests anywhere in src/api/groups/.

Proposed deepening

Split the flag into two query modules (useUserGroupsQuery / useAllGroupsQuery for admin), and put member/profile/count resolution behind one shared resolver that all group and group-vote modules consume.

Relations

Umbrella over two perf tickets whose fixes would land inside the resolver instead of per-file:

• perf: batch N+1 per-row Supabase queries into single .in() calls #161 — N+1 batching (covers addMemberCounts and useGroupMembers)
• perf: collapse useGroupVotes' three round-trips into one embedded-select query #168 — useGroupVotes' three sequential round-trips → one embedded select

Also relates to #123 (Active Group foundation), which will lean on group membership reads.

Architecture note

Explore ticket from the 2026-07-13 architecture review (candidate 6). Design to be settled in a grilling session before implementation. Vocabulary per /codebase-design.