Validate upstream JSON-RPC responses in transparent proxy

[bishnubista]

Summary

The transparent proxy (thv run) currently forwards upstream MCP server responses to clients with HTTP 200 even when the JSON-RPC frame is structurally invalid — missing jsonrpc:"2.0", invalid id type, non-object body, etc. The proxy sits between potentially untrusted upstream MCP servers and trusted clients, so a compromised or misconfigured upstream can push malformed frames straight through, where they may crash strict JSON-RPC parsers, be misinterpreted as legitimate responses, or trigger undefined behaviour in client-side parsers.

This PR validates upstream JSON-RPC frames at the proxy boundary and rewrites invalid responses into a structured JSON-RPC error so the proxy stops being a silent amplifier for malformed (or adversarial) upstream servers.

• Validation runs in NoOpResponseProcessor.ProcessResponse (streamable-http / default transport). SSE is unaffected.
• Structural rules: single JSON value (trailing JSON rejected); object or non-empty array of objects; per object jsonrpc=="2.0", id ∈ {string, number, null}, exactly one of result/error; error.code must be an integer, error.message must be a string.
• Gating: POST + 200, application/json(-rpc) media type, non-identity Content-Encoding passed through untouched, request must carry an MCP streamable-HTTP signal (MCP-Protocol-Version or Mcp-Session-Id) so non-MCP JSON traffic flowing through the catch-all is not rewritten.
• Invalid frame → HTTP 502 with body {"jsonrpc":"2.0","id":null,"error":{"code":-32000,"message":"Invalid upstream JSON-RPC response","data":"<detail>"}}. -32000 is the JSON-RPC implementation-defined server-error code; -32603 is reserved for internal JSON-RPC errors. Response headers are replaced wholesale so upstream Mcp-Session-Id, Set-Cookie, ETag, Cache-Control, etc. are not smuggled into the proxy-generated error.
• Body reads bounded by io.LimitReader at maxJSONRPCResponseBytes = 100 << 20 (100 MiB), matching streamable-HTTP precedent in pkg/vmcp/client and pkg/vmcp/session/internal/backend. Oversized responses are rejected with the same 502 shape so the proxy cannot be amplified into a memory DoS.

Closes #5247

Type of change

• Bug fix
• New feature
• Refactoring (no behavior change)
• Dependency update
• Documentation
• Other (describe):

Test plan

• Unit tests (task test)
• E2E tests (task test-e2e)
• Linting (task lint-fix)
• Manual testing (describe below)

Local verification:

• go test ./pkg/transport/proxy/transparent/... -count=1 — pass.
• golangci-lint run --timeout=5m ./pkg/transport/proxy/transparent/... — 0 issues.

New test cases in pkg/transport/proxy/transparent/response_processor_test.go:

• Valid pass-through: result, error, batch, result: null, application/json; charset=utf-8.
• Invalid → 502: missing jsonrpc, invalid id type, non-object body, result+error both present, trailing JSON, fractional error.code.
• Non-validated pass-through: non-POST, non-200, non-JSON, text/event-stream, application/jsonsomethingelse.
• Compressed responses (Content-Encoding: gzip) passed through unchanged for both valid and malformed payloads; explicit Content-Encoding: identity still validates.
• MCP-signal gate: no MCP request headers → pass through even with malformed body; MCP-Protocol-Version or Mcp-Session-Id → validate.
• Rewritten 502 strips Mcp-Session-Id, Set-Cookie, Etag, Cache-Control from the response.
• Oversized response (> maxJSONRPCResponseBytes) is rejected with a size-limit error.

API Compatibility

• This PR does not break the v1beta1 API, OR the api-break-allowed label is applied and the migration guidance is described above.

No CRD or operator API surface is touched.

Does this introduce a user-facing change?

Yes. Clients of the transparent proxy that previously received malformed upstream responses verbatim with HTTP 200 will now receive HTTP 502 with a synthetic JSON-RPC error body. Conformant upstream MCP servers are unaffected — only structurally invalid responses are rewritten.

Special notes for reviewers

Two scope decisions called out explicitly so reviewers can push back if either is wrong for the project:

1. Validation runs in ModifyResponse, after tracingTransport.RoundTrip may have observed an upstream Mcp-Session-Id and registered proxy-side session state. This PR strips upstream session headers from the proxy-generated 502 so clients never receive a session id derived from a malformed initialize response, but it does not roll back server-side proxy session state created before validation. Moving validation earlier (or adding a rollback path for invalid initialize responses) touches tracingTransport and felt outside the scope of "structurally validate the upstream frame." Happy to open a follow-up — or fold it into this PR if maintainers prefer.

2. Backward-compat clients that POST without MCP-Protocol-Version on the very first initialize will not trigger validation — same as today's behaviour, so no regression. If broader coverage is preferred, tracingTransport.RoundTrip already buffers and parses the request body to detect initialize; a small context-propagated marker would let ProcessResponse validate those frames too. Easy follow-up.

Open to feedback on:

• The 100 MiB body cap (matched pkg/vmcp precedent; can tighten to 10 MiB if maintainers prefer an explicit security default).
• Whether the MCP-signal narrowing should be widened to also accept the buffered-request-body sniff above.