Group management denies access even when user IS the group's Organizer

## Bug Navigating to the group management page shows the error **"You do not have permission to manage this ring."** — even when the current user IS the group's **Organizer** (the `ring_organizer` role on that group). See screenshot: `alexis` (the logged-in user) is the Ring Organizer of the group, yet the page rejects them at the permission check. ## Expected Users with `ring_organizer` (Organizer) or `co_organizer` roles on the group should see the management page. Only non-organizer members / non-members should hit the permission error. ## Reproduction 1. Log in as a user who is the **Organizer** of a group (verify: their role badge reads `Ring Organizer` on the group members list). 2. Navigate to the group's management surface (settings / manage members route). 3. Observe: red error text "You do not have permission to manage this ring." renders instead of the management UI. ## Likely root cause Something in the permission check is mis-identifying the user's role on this group. Candidates: 1. **Wrong role source**: the page checks `OrgMembership.role == "owner"` (org-level) instead of `GroupMembership.role IN ("organizer", "co_organizer")` (group-level). Being a group Organizer doesn't imply org Owner — the check looks at the wrong table. 2. **Stale role cache**: the client-side user/session store has a stale role for this group — created before the user was promoted — and the page reads from that stale state instead of re-fetching. 3. **Role name mismatch**: backend returns `"ring_organizer"` but the frontend predicate checks `"organizer"` (or vice-versa). Related to the rings → groups terminology cleanup (OP #5871). 4. **BFF slug-resolution pattern**: same class as Fider #67 / OP #5861 — BFF resolves `{group_slug}` via the user's own group list and takes a weird path. ## Investigation - DevTools → Network on the failing page: which endpoint returned 403 / permission? Capture the response JSON — role field empty, wrong, missing? - Same session: `GET /v1/groups/{slug}/members` — confirm the current user row returns role = `organizer` (or whatever the canonical value is). - Grep the frontend for the user-visible string `"You do not have permission to manage this ring."` — find the component and read its permission predicate. - Compare with the group public page where the Organizer role DOES render correctly (the badge shown in Fider #76 screenshot). The manage-page predicate must diverge from the public-page predicate. ## Impact - Group Organizers locked out of their own group's management — can't edit settings, manage members, configure the group. - Blocks every workflow that depends on group-level admin. - Reproducible; hits the primary user of the management surface. ## Related - **Fider #68 / OP #5863** — "Ring creator not promoted to organizer; org owners have no permission to manage rings." The creator-promotion half is fixed per code audit; the *org owner can't manage sub-groups* half remains. This bug may be the same root cause showing through for real Organizers. - **Fider #76** — missing Organizer promotion in group member-action menu. If the menu is gated by the same broken predicate, both share a fix surface. - **Fider #67 / OP #5861** — BFF slug-resolution pattern for group routes. ## Found by Manual testing