Bug: `_handleSseStream` retains reader lock on stream close, leaking ~50MB per reconnection

Summary

StreamableHTTPClientTransport._handleSseStream (dist/esm/client/streamableHttp.js:158-255, present in 1.29.0) acquires a ReadableStream reader via .getReader() but never calls reader.releaseLock() on either path:

• Success path (while (true) { ... if (done) break }): the loop breaks without releasing.
• Error path (catch (error)): the catch branch invokes onerror and possibly _scheduleReconnection, but never releases.

When the stream closes (server-initiated disconnect, abort, or error), the reader keeps its lock on the upstream ReadableStream. The TextDecoderStream and EventSourceParserStream buffers it pipes through remain reachable from the locked reader and stay GC-pinned. Each subsequent reconnection allocates a fresh pipeline, so memory grows ~50 MB per reconnect cycle in long-running clients.

Repro

A client that reconnects to an HTTP/SSE MCP server (streamableHttp transport) over a session that experiences any disconnect:

1. Connect via StreamableHTTPClientTransport.
2. Force a server-side disconnect (e.g., 504, idle timeout, restart).
3. Heap-snapshot before/after the reconnect — observe retained Uint8Array decoder buffer + parser state with ReadableStreamDefaultReader as the dominator.

Proposed fix

Wrap the while (true) { reader.read() } loop in try { ... } finally { reader.releaseLock() }:

const reader = stream.pipeThrough(...).pipeThrough(...).getReader()
try {
  while (true) {
    const { value, done } = await reader.read()
    if (done) break
    // ... process event
  }
} finally {
  reader.releaseLock()
}

The fix needs to live inside the existing outer try/catch so reconnection scheduling on catch still fires after the lock is released.

Notes

• Upstream Claude Code (the claude-code CLI, internal source) has this fix as of v2.1.117. The published @modelcontextprotocol/sdk package does not.
• I'm carrying a subclass override (LeakFreeStreamableHTTPClientTransport) that copies _handleSseStream byte-for-byte from 1.29.0 and adds the try/finally. Happy to open a PR with the upstream fix if it'd be useful.

🤖 Generated with Claude Code

Start in dist/esm/client/streamableHttp.js:158-255 and inspect StreamableHTTPClientTransport._handleSseStream, especially the reader loop and its surrounding try/catch. Reproduce a disconnect and reconnect if possible, then verify that the reader lock is released on both success and error paths while reconnection scheduling still occurs.