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

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.

Start by locating the provider endpoint matching, dynamic token-grant resolution, and outbound header-injection entry points; the issue names no files or tests. Use the acceptance criteria to define coverage for independent grants, failure atomicity, conflicts, redaction, caching, and isolation; done means all listed security and concurrency behaviors are verified.