feat: org switching

[marcorivm]

Slice 4 of #20, stacked on #25. 13 files, ~430 lines. Unblocked by the v1.45.0 adoption, which brings DEFAULT_ORG_COOKIE.

The gap

Multi-org membership was already ordinary and already unreachable. bootstrapOrganization gives every user their own org as owner; accepting an invitation adds a membership in someone else's. So anyone who has accepted an invite belonged to two organizations with no way to see or switch between them.

The blocker was precedence, not UI

session.ts derives organizationId from the resolved project and ignores x-organization-id whenever a project resolves — which on flat editions is always, because resolveProjectId falls back to findUserDefaultProject. The org header was simply dead there.

Fixed by making the fallback org-aware rather than inverting precedence:

findUserDefaultProject(userId, preferredOrgId?)

Switching org now means "land on my default project within that org". Org still derives from the winning project, so the two can never disagree — which is what makes the existing design coherent. Inverting precedence instead would have touched the lockout invariant and opened a mismatch class, since resolveProjectId validates a project against any org you belong to, not the selected one.

The fence only ever narrows

Two properties, both tested:

• The active-membership gate still applies, so a forged X-Organization-Id cannot promote a stranger's project.
• A preference that resolves nothing falls through to the unfenced answer. That fallback is the lockout guard: a stale selection — org left, membership suspended, its last project deleted — must not resolve to no project, or session auth 401s the user everywhere.

hasResolvableProjectExcluding deliberately does not learn about orgs

This is the invariant #20 flagged as the highest-risk edit in either scope, so it's worth being explicit. The two predicates must describe the same set of resolvable projects; the preference changes only which one wins. Fencing the oracle too would make it answer a narrower question than the delete guard asks ("will this user resolve something afterwards?") and reintroduce the lockout. A test asserts the two still agree.

Switching clears the project cookie

Non-negotiable: a project cookie from the previous org would otherwise win, because the project header takes precedence and the org is derived from it. You'd switch org and stay put.

Smaller choices

• GET /v1/organizations mirrors /v1/projects' guard stack, including the scope === "project" fence — a leaked agent key must not enumerate its owner's other organizations. Read-only, so nothing to audit.
• Suspended memberships are excluded: a switch there would resolve to nothing.
• The switcher renders only with 2+ memberships — gated on the count, not an edition flag, so it appears exactly when useful (single-org-shared has one org by construction).
• Like the project switcher, switching clears the whole query cache: getOrganizationId() is an undefined stub, so no query key changes.

Tests

7 new (organization-service.test.ts), covering the preference winning over an older project elsewhere, the fallback when it resolves nothing, the forged-header case, agreement with the lockout oracle, and the org list's active-only/role/foreign-org behaviour.

pnpm --filter @onecli/api test   # 1212 passed
pnpm --filter @onecli/web test   # 13 passed
cargo test -p onecli-gateway     # 615 passed
pnpm run check                   # 9/9