OTEL: Add error.type and rpc.response.status_code for JSON-RPC errors

Context

Identified during the OTEL MCP semantic conventions review (parent issue: #3399). These two spec gaps are related and should be implemented together since they both require the same response-body inspection approach.

error.type missing for JSON-RPC errors and tool_error

Severity: Medium
File: pkg/telemetry/middleware.go

error.type is only set for HTTP 5xx errors. JSON-RPC errors returned in HTTP 200 responses (e.g., -32601) and failed CallToolResult ("tool_error") are invisible to telemetry. This is acknowledged in code comments as future work.

Fix: Would require response body inspection — buffer/parse the JSON-RPC response to detect error codes and tool errors.

Missing rpc.response.status_code for JSON-RPC errors

Severity: Low
File: pkg/telemetry/middleware.go

The OTEL RPC semconv includes rpc.response.status_code for error responses. Would require response body parsing for JSON-RPC error codes.

Fix: Same response-body inspection approach as above.

Implementation considerations

• Both require intercepting/buffering the response body before it's written to the client
• Need to parse JSON-RPC response to extract error codes (e.g., -32601, -32602) and CallToolResult.isError
• A tee-style response writer that captures the body while still streaming to the client would be one approach
• Should set error.type to the JSON-RPC error code string (e.g., "-32601") or "tool_error" for failed tool calls
• High value for observability — currently JSON-RPC errors are invisible in telemetry since they return HTTP 200

Start by reading pkg/telemetry/middleware.go, including its comments and current response handling. Trace how JSON-RPC responses and CallToolResult values can be inspected, then verify that JSON-RPC error codes and tool_error produce error.type and rpc.response.status_code while HTTP 200 responses remain available to clients.