fix(security): bind OIDC providers to trusted tenants - #179

Summary

Bind every catalog-backed OIDC provider and static JWT provider to an explicit, trusted NodeDB tenant. Authentication now derives the session tenant from provider configuration rather than the token's tenant_id claim.

Security behavior

• Routes providers by issuer and audience instead of issuer alone.
• Allows a shared issuer across tenants only through distinct, non-empty audiences.
• Rejects duplicate or ambiguous provider routes and duplicate static provider names.
• Rejects legacy catalog providers without a tenant binding and static configurations that omit one.
• Revalidates catalog tenant existence before issuing an authenticated identity.
• Keeps HTTP authorization context aligned with the verified provider-bound identity.
• Returns indistinguishable client-visible errors for pre-authentication token failures.
• Isolates static and catalog JWKS cache domains with collision-free, endpoint-bound identities.

DDL and configuration

CREATE OIDC PROVIDER now requires TENANT <id>, persists the binding, validates the referenced tenant, and exposes it through SHOW OIDC PROVIDERS.

Static providers now require tenant_id in auth.jwt.providers. Missing bindings fail startup validation rather than falling back to token claims.

Compatibility

Persisted catalog records remain deserializable through an optional compatibility field, but unbound records fail authentication until recreated with an explicit tenant. This intentionally fails closed.

Validation

• Expanded parser, catalog OIDC, static JWKS, and verified AuthContext regression coverage.
• Focused Nextest suites pass.
• All-target, all-feature Clippy passes with warnings denied.
• Formatting, diff hygiene, production file-size limits, and independent security review are clean.