feature: Surfacing outbound pipeline denials

Feature Description

Due to Cortex's architecture and implementation as a transparent sidecar, currently when an outbound pipeline plugin (e.g. token-exchange or session-budget #723) denies or fails a request, the HTTP error (403, 503) is returned to the agent's internal HTTP client and not to the original caller. On the rossoctl platform this surfaces as a potentially cryptic error message like "can't connect to MCP service" instead of the a structured error message showing the original error.

The gap: there's no contract between a sidecar-injected policy denial and an agent SDK. HTTP SDKs don't distinguish "upstream is down" from "a policy layer rejected your request."

Reproduction

Point the token-exchange plugin at an unreachable Keycloak with default_policy: "exchange" and no_token_policy: "client-credentials". Any outbound request returns 503 with {"error":"upstream.token-exchange-failed","message":"client credentials token acquisition failed"} but an agent deployed on rossoctl will surface a generic error.

Proposed Solution

Up for discussion, and may depend on how 'transparent' a sidecar we want cortex to remain, such as for a solution like response injection. This could also be surfaced through events more clearly.

Want to contribute?

• I would like to work on this issue.

Additional Context

• MCP traffic already has protocol-native error wrapping (JSON-RPC error frame). The gap is for non-JSON-RPC outbound traffic (LLM inference, raw HTTP)
• Affects all deployment modes (proxy-sidecar, envoy-sidecar)

Start by tracing how the token-exchange and session-budget outbound denials travel through the proxy-sidecar and envoy-sidecar deployment paths. Review the existing MCP JSON-RPC error wrapping and compare it with raw HTTP and LLM inference failures. Done means the project has an agreed contract and a documented way for original callers to receive structured policy or upstream errors.