Half-onboarded org fixture

Scope: producing the fixture the UX-4 "waiting on owner" banner needs — a non-owner member of an org whose onboarding gates are still tripped (FLOW-002). Not the banner's behavior itself (→ portal-app/onboarding).

Source-checked against optolink-portal @ 7d31d45 and optolink-backend @ 29f8589, 2026-10-06 (WaitingOnOwner in src/app/(auth)/onboarding/page.tsx: banner text with owner name, fallback string without; RequireOrg gates on the onboarding state and routes to /onboarding; the invite endpoint stamps publicMetadata.optoRole backend-side, and acceptance applies the invitation's optoRole to the membership — team.controller.ts, clerk-sync.service.ts). OTP 424242 and Testing Mode are instance config — see clerk-dev-instance.

Base fixture: [email protected] / Ux357Verify!2026 — owner of an org parked at wizard step 3 (app-config saved, plan NULL).

Sign in as the owner → /settings?tab=team → invite [email protected] as Viewer (the backend stamps the Clerk invitation with publicMetadata.optoRole=viewer).
Register the invitee at /register using that +clerk_test email (password of your choice, OTP 424242) → accept the pending org invitation → the organizationMembership.* webhooks mirror the member and stamp publicMetadata.role=viewer (relay must be live — webhook-event-mirroring, path 1).
As the invitee: open / — RequireOrg routes to /onboarding → step-3 chrome (stepper marks "Your plan") with the info banner "Setup is waiting on your organisation's owner, {owner name}. Ask them to complete configuration & plan selection." — no plan cards mounted.
Direct-API fallback if the relay is down: create the user + membership via POST /v1/organizations/{orgId}/memberships (form-encoded user_id, role=org:member), then stamp PATCH …/memberships/{mid} with publicMetadata={"role":"viewer"} — and expect the banner's owner-name fallback ("your organisation's owner") until the local OrgMember row syncs.

Cleanup (cleanup.md): delete the invitee user; the org stays parked at step 3 for reuse.