BFF returns 404 for public org members when viewer is not a member

## Bug `GET /api/organizations/{slug}/members` returns **404 "Organization not found"** when the authenticated user is **not a member** of the org being viewed — even though the org is public and exists. Reproduces with any limit (e.g. `?limit=9&offset=0` or `?limit=1&offset=0`). The org's profile page loads fine in the same scenario, so this only affects the members list. ## Root cause `src/app/api/organizations/[slug]/members/route.ts` resolves slug → id by calling `resolveOrgId(slug)`, which scans the **authenticated user's own org list** (`/users/me/organizations`). If the visiting user is not a member of that org, the slug isn't in their list → the BFF returns 404, even though the org is public. The profile route works because it passes the slug straight to the backend (which accepts slugs). The same file (`resolveOrgId.ts`) already exposes a `resolveOrgIdPublic` function that queries `/organizations/browse` for exactly this case, but the members route never calls it. ## Expected A non-member viewing a public org should be able to load its members list (subject to the backend's own visibility rules). ## Fix (preferred) In `src/app/api/organizations/[slug]/members/route.ts`, cascade: try `resolveOrgId(slug)` first; on 404, fall back to `resolveOrgIdPublic(slug)`. Minimal change, matches the existing pattern in the file. A cleaner alternative is to mirror the profile route and pass the slug straight to the backend (assuming `/v1/organizations/{slug}/members` accepts slugs). Worth verifying, but a follow-up. ## Scope note Pre-existing bug — not introduced by OP#5389. Found while working in that area. ## Found by Manual testing