mcp: reject Subscribe on a closed session and roll back failed registrations

[GerardGao]

What

ClientSession.Subscribe (SEP-2575 path) starts a subscriptions/listen stream
without awaiting the send result, so on a session that is closing — or when the
listen send fails for any other reason — it can return nil even though the
stream never started. The local resourceSubs map also keeps an entry whose
cancel func is then never called, leaking the registration and misreporting the
URI as subscribed. Fixes #1171.

How

• Add a closed flag to ClientSession, set at the top of Close.
• Subscribe checks the flag under resourceSubsMu before registering, so a
  call after Close has started returns ErrConnectionClosed and registers
  nothing. Because the check and the registration share the mutex with the
  Close cleanup sweep, a racing registration is either swept by Close or
  refused outright — no interleaving leaks.
• If subscriptionsListen reports an error, the registration is rolled back
  (entry removed and cancel func called), so a later Subscribe retries the
  listen instead of treating the URI as already subscribed.

Unsubscribe and idempotent double-Subscribe behavior are unchanged.

Tests

• TestResourceSubscriptions_SubscribeClosedSession: Subscribe after Close
  returns ErrConnectionClosed and leaves no resourceSubs entry.
• TestResourceSubscriptions_SubscribeListenFailureRollsBack: a failed listen
  send (injected via AddSendingMiddleware) rolls back the registration and a
  retry re-attempts the listen.
• TestResourceSubscriptions_SubscribeCloseRace: 50 rounds of racing Close
  and Subscribe asserting that a failed Subscribe never leaves an entry.

go test -race ./mcp/ and go test ./... pass; gofmt, go vet, and
staticcheck are clean.

[GerardGao]

Rebased onto latest main (3632967) — this branch was 15 commits behind. No conflicts, and the diff is unchanged.

I also noticed no CI has run on this PR since it was opened. I think it needs a maintainer to approve the workflow run, since this is my first contribution to this repo — happy to be told if something else is blocking it instead.

On the overlap question: #1221 also touched mcp/client.go, but it changes the capability check in Connect, while this PR touches the ClientSession field, Close, and Subscribe. They don't overlap, and Subscribe on main still returns subscriptionsListen's result directly with no rollback, so #1171 is still reproducible.

To confirm the change is actually load-bearing, I ran a deterministic oracle rather than relying on winning the race: Close sweeps resourceSubs to nil, so sequencing Close fully before Subscribe reliably hits the post-sweep window. On exact base 3632967 that fails 5/5 with Subscribe-after-Close returned err=<nil>; resourceSubs entries=1 leaked=true — the entry is registered into a freshly allocated map that nothing will ever cancel, since Close has already run. On this head the same oracle passes 10/10 with err=connection closed; entries=0 leaked=false.

Verification on the rebased head, mirroring this repo's CI: gofmt/go vet/staticcheck v0.6.1 clean, go test ./... passes on both 1.25 and 1.26, go test -race ./... passes, docs are up-to-date, and both conformance suites pass against the baseline (client 460 passed, server 42/0 — including resources-subscribe and resources-unsubscribe).

Since #1171 isn't labelled help wanted and I didn't check in on the issue first, do say if you'd prefer a different approach here — happy to rework or close it.