Audit records outcome=success for JSON-RPC error bodies over 512 bytes #6720

Bug description

The audit middleware's JSON-RPC error detection stops working once a response body is larger than its 512-byte detection buffer, and the event is recorded as outcome: success.

errorDetectionBufferSize is 512 (pkg/audit/auditor.go:110-114) and responseWriter.Write copies only the bytes that fit, truncating the rest (pkg/audit/auditor.go:145-153). detectApplicationError then hands that prefix to mcp.ParseMCPResponse (pkg/audit/auditor.go:456-469), which is deliberately lenient and returns HasError=false when json.Unmarshal fails (pkg/mcp/response.go:39-46). A truncated JSON object is not valid JSON, so outcome stays OutcomeSuccess (pkg/audit/auditor.go:300-308) and no jsonrpc_error_code / jsonrpc_error_message metadata is attached.

The config contract says a prefix is buffered "to detect JSON-RPC error fields, independent of the IncludeResponseData setting" (pkg/audit/config.go:45-49, and the same wording in docs/operator/crd-api.md and the vMCP CRD), with DetectApplicationErrors defaulting to true. For error bodies over 512 bytes the operator gets neither the error nor any hint that detection was skipped, which is the failure class #4678 was filed about.

The streamable-HTTP proxy writes a JSON-RPC response in a single Write (pkg/transport/proxy/streamable/utils.go:134), so the cut lands mid-string.

Steps to reproduce

Any tool call whose JSON-RPC error body exceeds 512 bytes. Mirroring the truncation and ParseMCPResponse semantics outside the repo:

message=  440 body=  501 prefix=501 detected=true
message=  450 body=  511 prefix=511 detected=true
message=  460 body=  521 prefix=512 detected=false
message= 2000 body= 2061 prefix=512 detected=false

With an envelope of {"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"…"}} (63 bytes of overhead) the cut is at a ~449-character message. Error bodies that large come from servers that put a stack trace or the offending input in error.data, and from the proxy's own wrapped upstream failures.

Expected behavior

detectApplicationErrors: true should classify any JSON-RPC error response as outcome: application_error, or the record should say why it could not.

Actual behavior

outcome: success, with no error code or message, for every JSON-RPC error body over 512 bytes.

Environment (if relevant)

• ToolHive version: main @ dfb0713
• OS/version: darwin (analysis only; the numbers above come from a standalone program that copies the two functions, not from task test)

Additional context

I looked at three shapes for a fix and did not want to pick one unilaterally:

1. Grow the buffer. Simple, but the size that is "enough" is a guess, and a large error.data would still be missed.
2. Detect the error field incrementally while streaming, instead of parsing a prefix (e.g. a json.Decoder token walk that stops at the top-level error key). Handles unbounded bodies without buffering them.
3. Record outcome: unknown (or attach a detection_truncated: true marker) when the body was cut off, so the record is never silently positive.

I lean towards 2, with 3 as a cheap safety net, but 1 would also fix the common case. Happy to be assigned and put up a PR with tests either way — I did not find an existing test that feeds a response body over the buffer size through the middleware.