feat(providers): support multiple dynamic credential injections on one request

Inizia individuando i punti di ingresso per la corrispondenza degli endpoint dei provider, la risoluzione dinamica delle concessioni di token e l'iniezione degli header in uscita; l'issue non indica file né test. Usa i criteri di accettazione per definire la copertura delle concessioni indipendenti, dell'atomicità in caso di errore, dei conflitti, della redazione, del caching e dell'isolamento; il lavoro è completato quando tutti i comportamenti di sicurezza e concorrenza elencati sono verificati.

Summary

Support multiple independently resolved dynamic credential injections on one matching outbound HTTP request, including a SPIFFE JWT-SVID in a configured custom header and an independent Authorization: Bearer access token.

Problem

The POC has an outbound route where two separate security layers protect the same request:

1. An identity-aware proxy or service requires a dynamically obtained SPIFFE JWT-SVID in a configured custom header.
2. The destination service requires a separately acquired short-lived bearer access token in Authorization.

Providers v2 can describe bearer or custom-header placement for a dynamic token grant, but the provider/request contract needs to support composing multiple dynamic credentials for the same endpoint without materializing either token in the agent environment or adding an application-side proxy.

This is not a request to duplicate one token into arbitrary headers. Each injection has its own issuer, audience, scopes, cache lifetime, and failure semantics.

Requested behavior

• Allow a provider endpoint to reference multiple dynamic token-grant credentials for one request.
• Resolve and inject each credential only after endpoint and L7 policy admission.
• Support at least:
  • injection of a SPIFFE JWT-SVID into a provider-configured custom header for Teleport-based or other SPIFFE-compatible services;
  • an independently resolved Authorization: Bearer <token> credential for the destination service.
• Keep grant configuration independent per credential: token endpoint, JWT-SVID audience, resource audience, scopes, header placement, and cache TTL.
• Define deterministic conflict behavior when the agent supplies either protected header. The default should replace or reject according to explicit provider policy, never silently forward an untrusted agent value.
• Resolve all required credentials before forwarding; if any grant fails, inject none and fail closed.
• Redact both credentials from agent-visible state, logs, traces, errors, and policy events.

Acceptance criteria

• One HTTPS request matching a provider endpoint can receive both a SPIFFE JWT-SVID in a provider-configured custom header and an independently acquired bearer token.
• The two grants may use different token endpoints, audiences, scopes, and cache expiration times.
• Actual credential values and reusable credential handles are never exposed to the sandbox or agent. A non-secret opaque placeholder may be visible to the agent, provided credential substitution remains endpoint-scoped and enforced by the Supervisor.
• Header injection occurs only for the matched scheme, host, port, and path and only when TLS inspection is active.
• A failure in either grant prevents the upstream request and does not leave a partially injected request.
• Concurrent requests do not mix credentials across sandbox, provider instance, subject, audience, or endpoint.
• Tests cover cache hit/expiry, independent refresh, agent-supplied header conflicts, one-grant failure, redaction, and cross-sandbox isolation.

Example use case

Agent -> OpenShell Supervisor -> identity-aware proxy -> destination service

The Supervisor performs last-mile injection of:

1. A SPIFFE JWT-SVID required by the identity-aware proxy.
2. A separate short-lived bearer token required by the destination service.

The two credentials may have different issuers, audiences, scopes, token endpoints, and expiration times. Neither credential is exposed to the agent.