Validate the Streamable HTTP request-metadata headers (#110)

[TGoodhew]

Closes #110.

SEP-2243 mirrors a few body fields into HTTP headers so an intermediary can route without parsing JSON. That only holds if the two agree — otherwise a load balancer and this server are acting on different requests — so a disagreement is HeaderMismatch (-32020) with a 400.

Header validation

• Mcp-Method must equal the body's method.
• Mcp-Name must equal params.name (or params.uri), decoded from the =?base64?…?= sentinel first — otherwise a tool named in anything but ASCII would look like a mismatch against its own body.
• MCP-Protocol-Version must equal what _meta declares.

Two-speed enforcement, like the rest of this revision: a request declaring 2026-07-28 must carry them; a 2025-06-18 client — which is every HTTP client we serve today — never sent them and isn't asked to start. What holds in both cases is that a header which is present must be true.

The rest of the issue's list

• GET and DELETE both answer 405. The GET stream became subscriptions/listen; DELETE tore down a session that no longer exists in the protocol — and never existed here, since no session id was ever minted. A client that never received one has nothing to tear down, so nothing can break.
• CORS drops Mcp-Session-Id, allows Mcp-Method / Mcp-Name.
• Mcp-Session-Id and Last-Event-ID are ignored, with a test proving no session id is ever echoed back.
• Batch arrays: kept. Batching left MCP in 2025-06-18 and nothing we serve sends one, but accepting it costs nothing and refusing would help nobody. The metadata headers describe one message, so a batch skips that validation — there is no meaningful Mcp-Method for an array of different methods. Now commented and tested either way, as the issue asked.
• x-mcp-header deliberately not implemented. It is optional for servers, and none of our tools would gain from having a parameter mirrored into a header for routing — nothing here is routed by tenant or region. Worth revisiting only if the HTTP transport ever sits behind something that routes on tool arguments.

Deliberately out of scope

The same spec section says an unimplemented method over HTTP should return 404 (with the JSON-RPC -32601 body) rather than 200. That is not on this issue's list and it interacts with the backward-compatibility probe, so I left it — happy to file it as a follow-up if you want it.

Verification

• 10 new tests — mismatch on Mcp-Method and on Mcp-Name; base64 sentinel decoded; agreeing headers accepted; an older client not asked for them; a new-revision client required to send them; a protocol-version header contradicting the body; stale session/resumability headers ignored and never echoed; GET and DELETE both 405; a batch still accepted and skipping header validation.
• Full suite green: 395 GpibMcp + 113 Hpgl, 0 failures (Release|x86) — was 385 + 113.

README: the HTTP transport section covers the 405s and the header rules.