feat(providers): support multiple JWT-SVID audiences for SPIFFE credential providers

Start with crates/openshell-supervisor-network/src/token_grant.rs at the cited scalar-audience flow, then review the provider profile and runtime architecture documentation. Done means explicitly configured JWT-SVID audiences survive profile and API/SDK round trips, remain separate from the backend resource audience, preserve single-audience compatibility, and have the listed isolation, expiry, renewal, and integration coverage.

User Story

As an operator integrating a SPIFFE-aware credential broker and protected backend services, I want an OpenShell SPIFFE credential provider to request a JWT-SVID with an explicit list of audiences, so the same workload identity token can authenticate to both the broker and the intended backend without exposing credentials to agent code or forcing those services to share one audience identifier.

Problem Statement

The current token-grant configuration exposes a single jwt_svid_audience. Some workflows have more than one intended recipient of the workload's SVID:

1. A credential broker validates the SVID as a client assertion before issuing a delegated backend access token.
2. A backend service, or an identity-aware proxy in front of it, independently validates the workload SVID on the outgoing request.

The SVID's sub identifies the workload. Its aud identifies the services allowed to consume that particular token. The broker's audience and the backend's audience can therefore both be legitimate recipients of one deliberately scoped SVID.

This is distinct from the OAuth resource audience used to request the backend access token. Supporting several SVID audiences must not implicitly request multiple backend resources or broaden delegated access.

Impact / Why This Matters

A single-audience configuration cannot express this intent. Operators must arrange separate SVID acquisition, add credential-handling adapters, or configure otherwise distinct recipients to accept a shared audience. These alternatives add integration and rotation work or obscure the intended recipients.

Related open issue: #3320 — support multiple dynamic credential injections on one request. That issue covers setting multiple credential headers; this proposal covers requesting a single SVID valid for multiple explicitly configured recipients. Both capabilities are needed for the combined workflow below. Multi-audience issuance alone does not implement SVID forwarding.

Proposed Design

Allow an operator to declare multiple JWT-SVID audiences in a YAML provider profile. Illustrative syntax only; the final schema is up to maintainers:

token_grant:
  token_endpoint: https://credentials.example.org/token
  jwt_svid_audiences:
    - https://credentials.example.org/token
    - https://reports.example.org
  audience: https://reports.example.org/api

Desired workflow:

1. Supervisor obtains a signed JWT-SVID through the SPIFFE Workload API with both configured SVID audiences and the sandbox's workload identity.
2. Supervisor presents it to the credential broker as the client assertion, together with any separately required delegation or subject token.
3. The broker validates its own expected audience and independently enforces workload binding, delegation, scope and resource authorization before returning a backend access token.
4. With the injection support requested in #3320, Supervisor can reuse that SVID in a provider-configured identity header while injecting the separate backend token into Authorization on an admitted request.
5. Each recipient validates its own audience membership, signature, issuer/trust and expiration. An unrelated recipient is not authorized by this configuration.

Additional backend recipients should be explicitly configured only when the operator intends that same SVID to be accepted by them. Endpoint policy still independently determines where a credential may be sent.

Keep existing single-audience profiles and omission/default behavior compatible. Define an unambiguous rule when singular and plural forms coexist; rejecting conflicting configuration is preferable to silently widening the audience set. Do not interpret comma-separated text as a list or silently discard requested audiences.

Multi-audience use should be opt-in. A recipient holding the bearer SVID can replay it to another listed recipient, subject to that recipient's other authorization checks. Operators needing recipient isolation should retain separate single-audience SVIDs.

Acceptance Criteria

• A YAML-configured provider can request one JWT-SVID containing all explicitly configured audiences through a compatible Workload API implementation.
• Existing single-audience profiles continue to work, with documented handling of omitted, empty, duplicate and conflicting audience settings.
• Profile import/export and API/SDK round trips preserve the audience list without converting it into one comma-separated audience.
• SVID audiences remain independent of the resource audience and scopes requested for the backend access token.
• Credentials and grants cannot be mixed across workloads/providers or different requested audience sets; a configuration change cannot reuse an incompatible cached result.
• Expired SVIDs are never forwarded. SVID renewal preserves the configured audience set, and SVID/backend-token lifetimes are handled independently.
• In combination with #3320, an admitted request can carry the original multi-audience SVID and the independently obtained backend token without either becoming available to agent code, logs or errors. Acquisition failure fails closed.
• Integration coverage verifies acceptance by both configured recipients, rejection by an unrelated recipient, rotation/expiry, concurrent isolation and single-audience compatibility.

Alternatives Considered

• Separate single-audience SVIDs: offers stronger recipient isolation and remains a valid option, but does not cover operators deliberately choosing one SVID for several recipients.
• One shared audience configured on all recipients: avoids an audience-list requirement but no longer expresses each recipient's distinct identifier.
• External file/API adapters or a credential-injecting proxy: adds components and credential lifecycle handling outside the provider workflow.

Standards and Agent Investigation

RFC 7519 §4.1.3 permits an audience array. SPIFFE JWT-SVID §3.2 permits multiple audience values, requires recipient membership validation, and recommends a single audience for normal cases. This proposal enables the explicit multi-recipient case without changing the default.

Public source inspected at commit 99ed6a9df09a70981accfd39fe234fa1a648a93c: token_grant.rs takes a scalar audience and calls fetch_jwt_token([audience], None). The public provider profile and runtime architecture documentation were reviewed. No implementation is included in this request.

Checklist

• I've reviewed existing issues and the architecture docs.
• This is a design proposal, not a "please build this" request.