Handler-generated invalid params errors use HTTP 400 on the modern Streamable HTTP path #1320

Describe the bug

On the modern (2026-07-28) Streamable HTTP path, jsonrpc_http_status maps every ErrorCode::INVALID_PARAMS (-32602) response to HTTP 400. This includes ordinary application errors that the spec defines as -32602 and that are not transport validation failures:

• resources/read for a resource that does not exist (resources: Error Handling)
• prompts/get with an unknown prompt name or a missing required argument (prompts: Error Handling)
• tools/call for an unknown tool (tools: Error Handling)

The 2026-07-28 spec requires HTTP 400 for HeaderMismatch, UnsupportedProtocolVersionError, MissingRequiredClientCapabilityError, and for a request whose _meta is missing a required field such as clientCapabilities (_meta), and HTTP 404 for -32601. It does not require 400 for the handler errors above. Its backward-compatibility rules tell a client that receives HTTP 400 to inspect the body and fall back to initialize when it is not one of those recognized modern errors. A spec-compliant client could therefore treat a 400 carrying a "resource not found" -32602 as a legacy server and downgrade.

To Reproduce

1. Implement a ServerHandler whose read_resource returns Err(ErrorData::resource_not_found(...)) (or ErrorData::invalid_params(...) from get_prompt / call_tool).
2. Send a valid modern Streamable HTTP request with protocol version 2026-07-28 that reaches the handler.
3. Observe HTTP 400 with a JSON-RPC body containing error code -32602.

Expected behavior

Handler-generated -32602 errors should be sent with HTTP 200 as in-band JSON-RPC errors, like other handler errors that jsonrpc_http_status does not map. A request with malformed _meta should still be rejected with HTTP 400 and -32602.

Logs

actual:   HTTP 400, JSON-RPC error -32602 "Resource not found for URI: ui://widget/nope"
expected: HTTP 200, JSON-RPC error -32602

Found with rmcp 3.5.0 by MCPJam's modern-resource-not-found-invalid-params check (@mcpjam/sdk 8.20.1, profile mcp-protocol@2026-08-21.1), which expects an in-band error. The official conformance suite (0.2.0-alpha.11) does not check the status code for this case.

Additional context

The mapping is in jsonrpc_http_status:

https://github.com/modelcontextprotocol/rust-sdk/blob/8f9a28ecdb5f/crates/rmcp/src/transport/streamable_http_server/tower.rs#L646-L660

Only a missing protocolVersion is rejected in the transport with a direct HTTP 400 from invalid_params_jsonrpc_response. A request that has protocolVersion but no clientCapabilities reaches the handler and currently gets its 400 from this mapper. Removing INVALID_PARAMS from the mapper therefore also requires the transport to reject every missing required _meta field before dispatch.

#1303 is related. It makes malformed params for spec methods return -32602 instead of -32601, which fixes the 404, but with the current mapper those responses become HTTP 400.