Fix HTTP fallback error handling

[PranavSenthilnathan]

Structured HTTP 400 responses containing non-modern JSON-RPC errors now fall back from server/discover to initialize for both Streamable HTTP and AutoDetect.

AutoDetect now preserves HTTP semantics for structured non-modern JSON-RPC errors returned with non-400 statuses such as 401, 403, and 500. These responses remain HttpRequestExceptions with their status and body, without attempting initialize or deprecated SSE fallback. Streamable HTTP and AutoDetect share the same status/error-code classification so their behavior remains consistent.

The first fix is intentionally simple despite the architectural alternatives discussed in #1790. #1692 initially added a local transport validation exception when a modern response carried Mcp-Session-Id, together with a catch that prevented fallback for that exception. A later commit in the same PR updated the spec behavior to ignore unexpected session IDs and removed the local exception, but inadvertently left the catch behind. Removing that stale catch restores the intended fallback behavior; no provenance architecture or exception subclass is needed.

Validation:

• dotnet build --nologo passed.
• July2026ProtocolFallbackTests: 20/20 passed on net472, net8.0, net9.0, and net10.0.
• July2026ProtocolHttpFallbackTests: 8/8 passed on net8.0, net9.0, and net10.0.
• Broader managed test runs from the implementation sessions passed. The conformance CLI was blocked only by the local Node v21.6.2 environment lacking fs.globSync; this was not a code regression.

Fixes #1790

Note

This pull request description was drafted with GitHub Copilot.

[halter73]

I know this isn't new in this PR, but where did we get this list of three error codes? Looking at the "Backward Compatibility with Initialization-Based Versions" section in modelcontextprotocol/modelcontextprotocol#2844, I only see UnsupportedProtocolVersionError listed as indicating "the client retries with a supported version rather than falling back. Anything else identifies a legacy server."

I think this means that UnsupportedProtocolVersion should be treated differently in than the other error types like MissingRequiredClientCapability and HeaderMismatch for the purpose of server/discover fallback. In the future, when there's more than one protocol supporting server/discover, the supportedVersions included in this kind of error could be used to determine what older version of the protocol to make a subsequent server/discover call with.

I see modelcontextprotocol/modelcontextprotocol#2575 mentions MissingRequiredClientCapability, but not in a way that I think requires us to distinguish it from UnsupportedProtocolVersion.

Can we avoid classifying responses based on the JSON-RPC error code here? A non-successful HTTP response containing any JSON-RPC error should become an McpProtocolException, while other HTTP failures should remain HttpRequestException. McpClientImpl can then apply the protocol-specific retry or fallback policy.

[halter73]

Nit: Could we just do this for all the tests calling StartServerAsync and remove the acceptGet parameter? For tests where this matters, the handler could just return a 405 for GET requests manually, but I don't think that will be necessary.