fix(streamable-http-server): release the session map lock before waiting on a session

[TheSeydiCharyyev]

While one client's initialize is running, no other client can connect. Once a new client tries, requests on all other sessions wait too. With a server whose initialize takes 3 s, a second client's initialize took 2.8 s and a ping on an existing session took 2.6 s. With this change, both take about 3 ms.

Motivation and Context

LocalSessionManager keeps all sessions in one RwLock<HashMap<..>>. Five methods take the read guard and keep it while they wait on the session worker:

• initialize_session waits for the initialize response, so it keeps the guard during the whole ServerHandler::initialize.
• create_stream, create_standalone_stream and resume wait for the worker to reply.
• accept_message waits when the session's event channel is full.

create_session needs the write lock, so a new client waits for that guard. tokio's RwLock is fair: when a writer is waiting, new readers wait behind it. The tower service calls has_session for every POST and GET that has a session id, so requests on other sessions wait as well. The wait lasts as long as the slow initialize runs.

Fix

A private helper, session_handle, clones the LocalSessionHandle out of the map and drops the guard before the caller waits on the worker. The handle is only an id and a channel sender, so the clone is cheap. The five methods use the helper. close_session already drops the lock before it awaits; now the other methods work the same way.

How Has This Been Tested?

• New tests/test_streamable_http_session_isolation.rs. One session waits on its worker: nothing serves its transport, the same setup as test_streamable_http_init_timeout.rs. Then create_session and has_session for another session must finish within 1 s. There is one case for each of the five methods. On main all five cases fail with has_session blocked: Err(Elapsed(())). With this change they pass (30 of 30 runs).
• I reverted the change in one method at a time. Only the case for that method fails. Reverting initialize_session fails all five cases, because every case starts with a pending initialize.
• Over real HTTP (a local test, not in this PR): StreamableHttpService with a ServerHandler whose initialize sleeps 3 s, then a second client's initialize and a ping on an existing session. The numbers are at the top.
• cargo test -p rmcp with the CI feature set without local, for the 19 streamable HTTP server test files: all 152 tests pass. Also the nightly rustfmt check and both clippy commands from CI.

Tested on Windows 11.

Breaking Changes

None. The public API does not change: the helper is private.

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

Additional context

One small change in behavior: close_session no longer waits for calls that hold the read guard. The worker handles session events in order, so events queued before the close are still handled. Events queued after the close are not handled, and a call that waits for a reply gets SessionError::SessionServiceTerminated.