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.

[luisangelrod]

I reviewed the transport adoption and fallback split together with the new regression coverage. The behavior is consistent across direct Streamable HTTP and AutoDetect: structured 400 responses reach the protocol fallback policy, while structured non-400 HTTP failures preserve their status and body without attempting deprecated SSE fallback.

I also reproduced the focused test matrix locally on Windows with .NET SDK 10.0.203:

• July2026ProtocolFallbackTests: 20 passed on net472, net8.0, net9.0, and net10.0
• July2026ProtocolHttpFallbackTests: 8 passed on net8.0, net9.0, and net10.0

I found no additional blocking issues beyond the existing maintainer design discussion.

Disclosure: Drafted with AI assistance. I reviewed the diff and ran the tests reported above.