fix: keep handler-generated invalid params errors in-band

[DaleSeo]

Fixes #1320.

Motivation and Context

jsonrpc_http_status returned HTTP 400 for every -32602 error. That included regular application errors the 2026-07-28 spec defines as -32602, such as an unknown resource in resources/read, an unknown prompt or missing argument in prompts/get, or an unknown tool in `tools/call.

The spec requires HTTP 400 only for HeaderMismatch, UnsupportedProtocolVersion, and MissingRequiredClientCapabilityError. Its backward-compatibility rules tell clients to fall back to initialize if they receive any other 400. As a result, a spec-compliant client could mistake a "resource not found" error for a legacy server and downgrade. MCPJam's modern-resource-not-found-invalid-params check catches this.

When the transport itself rejects a malformed request, such as one missing _meta.protocolVersion, it still builds the 400 response directly in invalid_params_jsonrpc_response. Those responses remain unchanged.

How Has This Been Tested?

Added tests

Breaking Changes

There are no API changes, but clients may notice a change in the status code. A modern request with _meta.protocolVersion but no io.modelcontextprotocol/clientCapabilities now gets an HTTP 200 response with -32602 instead of an HTTP 400.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed