feat(proxy): preserve typed dynamic token-grant failures across the sandbox boundary

Summary

Preserve safe, structured dynamic token-grant failure classifications across the Supervisor proxy boundary instead of collapsing every token acquisition failure into an opaque 502 Bad Gateway.

Problem

During an integration POC with an external token service, an outbound request matched its provider policy and initiated the configured dynamic token grant. The upstream token service returned 401 Unauthorized, but the sandbox caller received only a generic 502 Bad Gateway.

This fail-closed behavior correctly prevented the request from reaching the destination without a credential. However, the trusted application/control plane could not distinguish an actionable authorization condition, such as a missing or revoked provider authorization, from invalid workload identity, token-service outage, timeout, or malformed configuration.

The sandbox must not receive raw token-service errors, token-service internals, authorization URLs, credentials, or identity details. A trusted caller still needs a stable classification so it can initiate the appropriate recovery flow.

Requested behavior

• Define a stable, sanitized error taxonomy for dynamic token-grant failures.
• Preserve a recognized token-service condition such as provider_authorization_required through the Supervisor/Gateway status or trusted control-plane API.
• Continue returning a non-sensitive, fail-closed error to the sandbox request.
• Distinguish at least:
  • provider/user authorization required;
  • workload identity or assertion rejected;
  • provider/token-grant configuration error;
  • upstream timeout or unavailable service;
  • unclassified upstream failure.
• Include a correlation ID that lets operators join the sandbox denial, Supervisor event, Gateway event, and token-service event without exposing tokens.
• Do not infer provider_authorization_required from every upstream 401; only propagate an explicitly recognized, authenticated contract from the configured token service.

Acceptance criteria

• A token service's authenticated, typed provider_authorization_required response is available to an authorized trusted control-plane client using a documented stable code.
• The sandbox response and sandbox-visible logs contain no token-service response body, authorization URL, bearer token, JWT-SVID, or provider secret.
• An invalid/expired JWT-SVID remains distinguishable from provider authorization required in trusted telemetry.
• 401, 403, 409, 429, timeout, and 5xx token-service cases have deterministic documented mappings.
• The enterprise request is never forwarded when token resolution fails.
• Unit and end-to-end tests cover the mappings, redaction, correlation, and fail-closed behavior.

Observed POC behavior

The proxy returned 502 while trusted OpenShell logs showed that the intermediate provider token exchange failed with upstream 401 Unauthorized. This RFE requests an error contract; it does not request exposing the raw upstream response to the agent.

Start by tracing the dynamic token-grant failure path across the Supervisor, Gateway, sandbox response, and trusted control-plane API. Review the configured token-service contract and existing telemetry boundaries, then use the acceptance criteria to define deterministic mappings, redaction, correlation, and fail-closed behavior. Add unit and end-to-end coverage for the listed status cases and ensure the trusted client receives only the documented stable classification.