feat: BYOK auth-passthrough — forward per-caller credentials to upstreams

[SPIKESPIGEL404]

Closes #11.

Summary

Adds an opt-in auth_passthrough mode to upstream config. When enabled, the gateway forwards each caller's own Authorization credential to the upstream instead of a statically-configured bearer_token.

This enables BYOK (bring-your-own-key): a fronting service can let each end user supply their own upstream provider API key, which the gateway relays per-request — without the operator holding a shared key for that upstream. Attestation, verification, channel binding, and receipts are unchanged.

Motivation

Today an upstream authenticates with a single operator-configured bearer_token (OpenAICompatibleBackend), and the caller's inbound Authorization is consumed only as a hashed receipt-owner tag — it never reaches the upstream. That's correct for a gateway fronting one account, but it blocks multi-tenant BYOK, where the gateway should relay each user's own provider key (e.g. a per-user NEAR AI key) while still doing the attested-confidential-inference work it exists for.

What this does

• New UpstreamConfig.auth_passthrough: bool (default false, serde-defaulted so existing configs are unchanged).
• When set, OpenAICompatibleBackend forwards the caller credential as the upstream Authorization and never uses a static token.
• The caller credential is threaded handler → service → backend via a new UpstreamRequest.client_authorization.

Security / design notes

This change moves a raw secret (the caller's bearer) along new code paths, so the handling is deliberately conservative:

• Redaction is structural, end-to-end. The credential is wrapped in a ClientAuthorization newtype whose hand-written Debug redacts, and it is carried as that type across every hop (ChatCompletionRequest, BackendForwardInput, UpstreamRequest). No struct carrying it derives Serialize, and none is logged. The raw key cannot reach logs, receipts, or the request store.
• Fail-closed precedence. In passthrough mode the static bearer_token is never sent. Config validation rejects setting both auth_passthrough and bearer_token on the same upstream, and an absent caller credential yields no Authorization header (a visible upstream rejection), never a silent fallback.
• Provider support is validated. auth_passthrough is only honored by providers served through OpenAICompatibleBackend (openai-compatible, aci-dcap, tinfoil, near-ai, phala-direct). Enabling it on a provider that ignores it (chutes, which uses its own E2EE transport) is rejected at config validation rather than silently no-op'ing.
• Middleware mode is unsupported, and fails closed. The middleware request store keeps only a hashed requester, so the raw credential isn't available on that path. The gateway now refuses to start if middleware mode is enabled together with any auth_passthrough upstream, rather than 401-ing every request at runtime.
• Credential normalization. extract_bearer strips/trims the Bearer scheme and the backend re-wraps it, so only a well-formed Bearer <token> is forwarded (no header-shape passthrough).

Scope / limitations

• Applies to the forwarding (POST) path. Server-initiated upstream GETs (e.g. model listing) are unaffected — under config-driven routing the model list is synthesized locally, so no per-caller credential exists there.
• In BYOK mode the receipt-owner tag becomes sha256(caller credential) (same as today's hashing of the inbound bearer); ownership semantics therefore bind to the provider key in this mode.
• Not wired for the Chutes E2EE transport (rejected at validation, see above).

Testing

• tests/provider_e2e.rs: new end-to-end test asserting the load-bearing properties against the mock-upstream harness — the caller credential reaches the upstream verbatim, and an absent credential results in no Authorization header (no static-token fallback).
• src/aggregator/upstream_config.rs: unit tests for the new validation rules (auth_passthrough defaults off and parses; rejected with a static bearer_token; rejected for an unsupported provider).
• cargo check --all-targets, cargo clippy --all-targets, and cargo fmt -- --check are clean. Full suite passes (lib + provider_e2e + aci_service_surface).

Backward compatibility

auth_passthrough is serde-defaulted to false; existing upstream configs and behavior are unchanged. PublicUpstreamConfig gains the field so the admin/read API reflects it.

[h4x3rotab]

Thanks for this, and for the clean PR. My pushback is about where it lives, not whether it's useful.

I don't want per-caller credentials handled inside the gateway core. Whose token gets forwarded is provider policy, and the gateway's job is to stay a thin, attestable base: verify upstreams, let clients verify the gateway, and host a middleware for exactly this kind of custom logic.

Your middleware already receives the caller's Authorization header today. What's missing is the mechanism to pass it on: a middleware can't yet hand the gateway a per-request upstream credential, and the backend overrides it with the operator key. I'd rather add that mechanism than merge BYOK into the core. I wrote up the details and am tracking the plumbing in #11.

Leaving this open. Let me know if that direction works for you.