mcp: prevent leaks of ServerSession on StatefulServer

[guglielmo-san]

Fixes #1136

[scottlz0310-user]

Thanks for the quick turnaround. I verified this branch (bfee8f4) as the reporter of #1136, and it fixes the leak.

Reproduction from #1136 — was FINAL leaked sessions = 3 on v1.7.0, now:

client 1 connected: negotiated=2025-11-25 sessions=1
client 1 closed   : sessions=0 (want 0)
client 2 connected: negotiated=2025-11-25 sessions=1
client 2 closed   : sessions=0 (want 0)
client 3 connected: negotiated=2025-11-25 sessions=1
client 3 closed   : sessions=0 (want 0)

FINAL leaked sessions = 0 (want 0)

The session count now stays at exactly 1 while a client is connected, instead of climbing by one per connection.

Other checks on this branch:

• go test -count=1 ./mcp/... — green.
• The new TestStreamableStateful_DiscoverDoesNotLeakSession — passes.
• The downstream project whose test suite regressed on the v1.6.1 → v1.7.0 bump (its test asserts that a stateful server reuses exactly one session across requests) is green again with this branch dropped in via replace, with no changes on its side.

Your approach is neater than the one I sketched in #1136. I proposed routing discover-only requests through the ephemeral path in serveStatefulPOST; gating the InitializeParams persistence on whether the transport can actually serve 2026-07-28 addresses the same root cause with a smaller change and lets the existing #578 safety net do the cleanup. The added regression test covers the coupling to that safety net, which was my only concern with relying on it.

Nothing further from me — happy to see this land.