Support multi-tenant AI routing via signed user context forwarding

Start by locating the backend handlers for ai-proxy, ai-transform, ai-translate, and their streaming path, then trace how upstream AI requests and authenticated OIDC context are handled. Done means optional, signed user-context forwarding works across all listed endpoints, remains disabled by default, and the proxy contract and security behavior are documented.

Feature Request

Is your feature request related to a problem or unsupported use case? Please describe.
Enable optional forwarding of authenticated user context (from external OIDC) in AI requests, so deployments can use a custom proxy for multi-tenant routing (per-user or per-organization provider/model/API key selection), while preserving the current single-key behavior by default.

Describe the solution you'd like
Add optional forwarding of user context from Docs backend to upstream AI API requests (including streaming path), so external proxies can apply custom routing and credentials.

Proposed behavior:

1. Keep current behavior unchanged by default.
2. Add config flags (env vars) to optionally forward user context in headers.
3. Forward signed token rather than raw PII.
4. Apply to all AI endpoints (ai-proxy, ai-transform, ai-translate).

Example config:

# Enable/disable forwarding (default: false)
AI_FORWARD_USER_CONTEXT_ENABLED=false

# Header name used to forward user context
AI_USER_CONTEXT_HEADER=X-Docs-User-Context

# Secret used to sign the header payload (HMAC)
AI_USER_CONTEXT_SIGNING_SECRET=...

My thoughts on the header content using SHA-256 HMAC using the AI_USER_CONTEXT_SIGNING_SECRET env variable, with payload being base64url-encoded JSON:

{
  "sub": "user_123",            // OIDC subject or internal user ID
  "iss": "docs-backend",    // optional issuer identifier
  "iat": 1710000000           // issued-at timestamp
}

My assumption would be the proxy runs in a trusted environment. If not, we would have to add things like a nocne and exp as short-lived expiration timestamp. Not required for my use-case, though (also exceeding what I'd be comfortable to implement).

Open questions

• Do we then also need a way to enable/disable UI features dynamically? Alternative 2 would make that easier; in this proposed approach it would only be possible via loading custom js.

Describe alternatives you've considered

1. Native per-user API key storage in Docs (more complex, broader product/security scope).
2. Dedicated key-resolution API that Docs calls per request (also more moving parts and caching complexity).

Discovery, Documentation, Adoption, Migration Strategy

• Backward-compatible and disabled by default.
• Document proxy integration with sample header contract and security notes.
• Optional minimal reference proxy can be provided in a separate repo.

Do you want to work on it through a Pull Request?
Yes. I can propose an initial PR for optional user-context forwarding and documentation, and optionally a separate reference proxy implementation.