Member app: group URLs resolve inconsistently by ID vs slug

[mbyrdLCS]

Summary

The member app's group route (/mobile/groups/{value}) appears to resolve group IDs in some sessions and only slugs in others, suggesting two disagreeing code paths or a caching layer behind the slug endpoint.

Observed Sequence (2026-06-11, demo church)

1. Morning: navigating directly to /mobile/groups/cYXjyXu5WSG (internal group ID) worked — full group page rendered with name, members, Leader badge, and the Events tab functional.
2. That group was later deleted; a new group with the same name ('General Service', slug general-service) was created (new ID ZWnh0-0_B3w).
3. Navigating to /mobile/groups/ZWnh0-0_B3w failed — the underlying call GET /membership/groups/public/{churchId}/slug/ZWnh0-0_B3w returned 200 {} and the page rendered the broken empty state (see Member app: group page renders broken skeleton state when group lookup returns empty (API returns 200 {} instead of 404) #909). This persisted for at least ~25 minutes across reloads and fresh logins.
4. Navigating to /mobile/groups/general-service (slug) worked immediately.

Why It Matters

• If ID-based URLs are not supported, they should never work (and should redirect or 404) — intermittent support means links that work today break tomorrow.
• Deleting and recreating a group with the same name silently breaks previously shared ID-based links.

Suggested Fix

Either add a deliberate ID fallback to the slug lookup (id first, then slug, or vice versa), or remove ID resolution entirely and 404/redirect consistently.

the group loaded by ID: broken empty page

the same group seconds later loaded by slug: name, member count, and Leader badge all present

Environment

Chrome desktop, signed in as group leader, demo church demo0626.b1.church.

[jzongker]

Deployed Ajay's fix