mcp: carry the SEP-2575 _meta envelope on notifications/cancelled

[yhxlele]

Fixes #1212.

The two cancellation-notify sites (cancelCall and the async-notify branch of call, both in mcp/transport.go) build CancelledParams directly, so they are the only client sends on a 2026-07-28 session that omit the SEP-2575 per-request _meta envelope. A conformant server rejects the notification with -32602 "missing or invalid _meta field \"io.modelcontextprotocol/protocolVersion\"" over HTTP 400, and because that rejection responds to a notification its error body has no id, so checkResponse cannot classify it as a per-call rejection (#1118) and permanently fails the connection. Net effect: ClientSession.Unsubscribe — or canceling any in-flight call — poisons the whole stateless session (see #1212 for the wire trace).

This change computes the envelope once per send in handleSend (cancellationMeta, nil for server sessions and pre-2026 protocols, reusing injectRequestMeta so the envelope stays identical to every other send) and threads it through call / callSubscriptionsListen into the two notify sites. With it, the cancellation is accepted (202) and the session stays usable.

Tests: TestSubscriptionsListen_CancellationCarriesMeta drives a real stateless server through both triggers (Unsubscribe of a listen subscription, cancellation of an in-flight tool call) and asserts at the wire that each notifications/cancelled carries the _meta protocol version and is answered 202, then that the session still serves tools/list. On main it fails with missing _meta "io.modelcontextprotocol/protocolVersion", got HTTP 400, want 202, and slow tool never started — session unusable after Unsubscribe; with this change it passes. go test ./... and go vet ./... are clean.

[yhxlele]

Closing in favor of #1215 — per the discussion in #1212, the schema defines the SEP-2575 triple for requests only, so the server-side relaxation is the right fix.