Perform SSE stream writes outside the session mutex

[koic]

Motivation and Context

StreamableHTTPTransport guards its @sessions and @pending_responses maps with one @mutex. The send paths wrote to an SSE stream while holding that lock: the targeted and broadcast branches of send_notification, the server-to-client send_request, and send_keepalive_ping all called send_to_stream/send_ping_to_stream (a stream.write plus stream.flush) inside @mutex.synchronize.

A stream write is blocking I/O with no timeout: if a client reads its SSE stream slowly, the server-side write waits until the socket buffer drains. Performing that write under @mutex serializes every other session on the same lock (head-of-line blocking): new initialize inserts, session validation, handle_response, the reaper, and delivery to other sessions all wait behind one slow reader. The broadcast path holds the lock across every session, so one slow stream also delays delivery to the sessions after it.

The cleanup paths already release the lock before touching a stream: they collect streams_to_close and call close outside synchronize. This change applies the same discipline to the writes.

• Each send path resolves its target stream under @mutex (and, for send_request, registers the pending response there), then releases the lock before writing.
• A write error still drops the broken stream. That teardown is centralized in a new drop_broken_stream, which mutates @sessions under @mutex and closes the affected streams outside it. A request-scoped stream is dropped on its own; a GET SSE failure removes the whole session, matching the previous behavior.
• send_notification splits into deliver_targeted_notification and deliver_broadcast_notification; the return values (true/false for a session, the delivered count for a broadcast) are unchanged.

How Has This Been Tested?

New tests in test/mcp/server/transports/streamable_http_transport_test.rb install a probe stream that records, via mutex.try_lock, whether @mutex is held during each write, and assert it is not held for the targeted notification, broadcast, send_request, and keepalive paths. Each new test fails against the previous code and passes now. The existing send and cleanup tests still pass.

Breaking Changes

None. Delivery semantics and return values are unchanged; the lock is simply no longer held while writing to a stream.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed