Build the tenant-picker backend protocol (no frontend yet, by design)

A multi-membership identity (belongs to more than one tenant) used to
get a flat 501 refusal -- named as undesigned future work across
CLAUDE.md/threat-model.md/the runbook since early Phase 4. Scope for
this change was agreed via AskUserQuestion: backend protocol only,
fully verified via real HTTP round trips, not the actual picker page --
web has zero session/cookie-handling code today (confirmed while
researching this), so building that is separately-scoped, unverifiable
frontend work in this environment (no live backend, no browser).

session.Manager gains IssuePendingLogin/ValidatePendingLogin, a second
JWT token type proving identity without committing to a tenant yet
(10-minute TTL). PendingLoginClaims is deliberately a distinct Go type
from Claims, and -- caught by this change's own test suite before it
shipped -- needed a JSON field name disjoint from Claims.UserID's
"user_id" too: go-jose's unmarshal is happy to populate a struct from
any token whose claims happen to share a key, so a real session token
would otherwise have parsed successfully as a pending login. Fixed via
"pending_user_id" instead; both directions (session-as-pending,
pending-as-session) now have regression tests.

rbacstore.ListMembershipsWithTenantForUser joins tenant_memberships
with tenants, since a picker needs display names, not just IDs.

loginhandler.resolveIdentity's multiple-membership branch no longer
errors -- finishLogin routes it into startTenantSelection instead,
which issues a pending-login cookie (Path=/auth, so it's never sent on
ordinary requests) and redirects to a new configurable
SelectTenantRedirectURL (defaults to {POST_LOGIN_REDIRECT_URL}/select-
tenant). Two new routes complete the round trip: GET /auth/memberships
lists the pending identity's real tenant options, and POST
/auth/select-tenant re-derives the role for the chosen tenant
server-side (never trusts a client-supplied role, refuses a tenant_id
outside the identity's actual memberships with 403) before issuing the
real session -- responding with JSON {"redirect_url": ...}, not a
redirect, since a POST/fetch caller should control its own navigation.

Verified with the same real-fake-IdP tests the rest of this package
uses (coreos/go-oidc's oidctest, crewjam/saml's samlidp): the full
login -> pending cookie -> GET /auth/memberships -> POST
/auth/select-tenant -> real session round trip for both protocols, plus
negative paths (missing/expired pending cookie, a tenant_id outside
membership, a real session token rejected as a pending login and vice
versa). ErrMultipleMemberships is removed -- it's not an error path
anymore.

Docs updated in lockstep: CLAUDE.md, threat-model.md (including its
summary table), phase-4-runbook.md (new §12), enterprise/README.md
(new "Tenant selection" section, explicit about what's still not built
and why: no session handling in web, no CORS on enterprise-auth).

CLAUDE.md

@@ -221,11 +221,21 @@ caller of ClickHouse/`rbacstore`, and (via a new
 its real result into the CRD — a real credential Secret, not the
 previous placeholder that authenticated against nothing, and status
 fields the reconciler derives `Phase`/`Ready` from instead of
-independently guessing "Active" the moment a Tenant object exists. What
-still keeps this phase from being done: ingest itself has no tenant
-concept for either storage engine (every record lands in the one shared
-ClickHouse database and Tantivy index no matter what — undesigned, not
-just unbuilt). Full accounting:
+independently guessing "Active" the moment a Tenant object exists. The
+tenant-picker's backend protocol is built too: an identity with more
+than one `tenant_memberships` row now gets a real `GET
+/auth/memberships`/`POST /auth/select-tenant` round trip (a short-lived
+pending-login token, distinct from a real session by both Go type and
+JWT claim name — a real token-confusion bug this design's own tests
+caught before it shipped) instead of the flat refusal Phase 4 shipped
+with earlier. What still keeps this phase from being done: the actual
+tenant-picker *page* doesn't exist (`web` has no session/cookie-handling
+code at all yet, and `enterprise-auth` has no CORS middleware for a
+cross-origin `fetch` with credentials — both real, separately-scoped
+frontend gaps), and ingest itself has no tenant concept for either
+storage engine (every record lands in the one shared ClickHouse database
+and Tantivy index no matter what — undesigned, not just unbuilt). Full
+accounting:
 `/docs/security/threat-model.md`; step-by-step verification procedure
 (not yet run against a live cluster in this environment):
 `/docs/phase-4-runbook.md`. The rest of this section describes the exit