refactor(auth): universal resolveUserOrgMembership helper for org auth-check pattern

[bokelley]

Summary

Closes the dev-mode-403 gap that bit me when verifying #3430 in dev mode: every admin-only org endpoint was 403'ing because WorkOS doesn't know about DEV_USERS, and the dev-mode bypass that solved this lived in exactly one place (GET /api/me/member-profile). Each route would need its own copy or stay broken in dev.

This consolidates the pattern.

What

New helper resolveUserOrgMembership(workos, userId, orgId) in server/src/utils/. Returns { role, status } | null. In dev mode it reads from local organization_memberships (seeded by dev-setup.ts at boot). In prod it defers to WorkOS as source of truth.

Refactors 14 call sites across organizations.ts and member-profiles.ts that did the inline WorkOS-membership-then-resolveUserRole pattern. Each becomes a one-liner:

// Before
const memberships = await workos.userManagement.listOrganizationMemberships({ userId, organizationId });
if (memberships.data.length === 0) return res.status(403)...;
const role = resolveUserRole(memberships.data);

// After
const membership = await resolveUserOrgMembership(workos, userId, orgId);
if (!membership) return res.status(403)...;
const role = membership.role;

Verification

• Typecheck clean.
• 129 integration tests pass on the impacted suite (8 new for the helper, plus all the existing org-routes-touching tests: membership-webhook, find-paying-org-for-domain, primary-organization-resolution, org-auto-provision-toggles, personal-workspace-restrictions, self-service-delete, join-request-approval, member-by-email-policy).
• Dev-mode end-to-end: Playwright smoke against the team page logged in as the dev admin user. Before this PR, /api/organizations/:orgId/{domains, roles, seat-requests, ...} all returned 403. After, every endpoint responds 200. The single remaining 404 (/api/billing) is unrelated.

Out of scope

• Routes that use listOrganizationMemberships for non-auth-check purposes (listing all members of an org, listing all of a user's orgs) are unchanged. The helper only replaces the userId+orgId filter pattern that's the canonical "is this user a member of this org?" auth check.
• The "list a user's primary org" path is already covered by resolvePrimaryOrganization from PR fix(membership): centralize primary_organization_id reads, add invariant #3375.

🤖 Generated with Claude Code

[bokelley]

Pushed round-2 fixups addressing the security + code reviews:

Security HIGH (resolved): Prod-boot guard added in auth.ts:485-510. If DEV_USER_EMAIL + DEV_USER_ID are set with NODE_ENV=production OR FLY_APP_NAME present (Fly.io always sets it), the process crashes at startup with a clear error. Override is ALLOW_DEV_MODE_IN_PROD=true for genuine one-offs. The blast radius widening (1 read endpoint → 23 mutating endpoints) is what made this newly load-bearing.

Code FBM (resolved): Refactored 6 more auth-check sites I missed in the original commit — the invitations crud, the resend endpoint, the members PATCH/DELETE, and the member-add path. The last one (members/by-email) needed a careful pattern-preserve because it conditionally skips the WorkOS lookup for the static admin API key; new code maintains that skip while routing through the helper for non-static-key callers.

Acknowledged but deferred (filing follow-up issues):

• billing-public.ts:253 isDevUserInvoice and certification.ts:25 isOrgMember — different patterns from the helper's signature; need their own analysis. Out of scope here.
• Dev-session cookie is unsigned (security medium). Pre-existing risk; the prod-boot guard makes the practical impact much smaller (cookie can only be exploited if dev mode actually leaks, which the guard now hard-prevents). Worth signing the cookie regardless — separate issue.
• DB isolation between dev/staging/prod (security medium, operational hygiene). Not in code; will document.
• Audit-log attribution under dev-bypass uses non-WorkOS-resolvable user IDs (security low). Acceptable today; revisit if dev-bypass usage grows.

All other items (vitest mock isolation, resolveUserRole filtering, semantic drift) confirmed lgtm by review.

Tests: 123 integration tests pass on the impacted suite.

[bokelley]

Round-2 fixups noted — prod-boot guard, 6 additional auth-check refactors, and the deferred items with follow-up issue plan all look well-reasoned. The members/by-email pattern-preserve for the static admin API key path is a good call. No action needed from triage here.

(Note for infra: this PR comment reached the triage routine rather than the auto-fix feature — filter gap to investigate.)

---

Generated by Claude Code