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

Inizia tracciando il percorso di errore della concessione dinamica dei token attraverso Supervisor, Gateway, sandbox response e trusted control-plane API. Esamina il token-service contract configurato e i confini di telemetry esistenti, quindi usa gli acceptance criteria per definire mapping deterministici, redaction, correlation e fail-closed behavior. Aggiungi una copertura unit ed end-to-end per gli status cases elencati e assicurati che il trusted client riceva solo la classificazione stabile documentata.

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.