feat: support shared-router multi-tenancy with isolated config scopes

Summary

Support multi-tenancy in one shared router instance by mapping trusted tenant identity to isolated routing/config scopes while sharing common model resources where safe.

Parent roadmap: #2287 Depends on: #2326, #2331 Related: #2286, #2330, #2356

Child issues

• #2362: Add trusted tenant identity resolution for shared-router multi-tenancy.
• #2363: Add tenant-scoped config snapshots and recipe activation.
• #2364: Define shared-resource isolation and diagnostics for multi-tenancy.
• #2356: Add tenant-aware quota, budget, and rate-limit policy.

Motivation

Today, per-tenant isolation generally requires separate router instances and duplicated model or embedding resources. Enterprise adopters want one router instance that can host multiple isolated tenant configs, with shared base resources and per-tenant overrides.

The codebase already has authz identity configuration, rate-limit providers, model runtime assets, replay, memory, cache, and dashboard control-plane surfaces. Multi-tenancy should compose those existing surfaces instead of adding a client-controlled tenant header in routing config.

Scope

Design and implement a tenant-aware config and routing model covering:

• trusted tenant resolution from API key/auth layer;
• stripping or ignoring client-supplied tenant identifiers;
• shared base config plus per-tenant overrides;
• independent tenant config versioning and activation;
• per-tenant recipe/entrypoint selection;
• shared model and embedding resources without config leakage;
• per-tenant quota/budget/rate-limit policy;
• diagnostics that avoid leaking raw tenant identities.

Non-goals

• Do not implement multi-tenancy as a client-controlled header without trusted auth.
• Do not duplicate all model resources per tenant by default.
• Do not bypass versioned config activation semantics.
• Do not let tenant identity resolution live inside recipe-local signal config.

Acceptance criteria

• A tenant identity can select an isolated config or recipe scope transparently to standard OpenAI clients.
• Tenant configs can be validated and versioned independently.
• Shared resources are explicit and safe.
• Quota/budget/rate-limit policy composes with tenant identity.
• Diagnostics expose tenant scope safely without leaking secrets or raw identifiers.
• Existing single-tenant configs continue to work unchanged.