to_mcp_server never deletes the ADK session of a dead MCP connection; stateless streamable HTTP leaks one session per tool call

Finding: In google-adk (reported on main at 7ae1c9b, Python 3.12, mcp 2.2.0, also 1.24.0 and 1.26.0), to_mcp_server keeps one ADK session per MCP connection in a weak-key map but never calls delete_session when the connection dies, so sessions stay in the session service. With stateless streamable HTTP each request gets a fresh transport, so each tool call reportedly leaves one new session. Source: https://github.com/google/adk-python/issues/7154 Reported evidence: the issue author's script makes 10 short in-memory MCP connections with one call each and reports 10 sessions left; a real stateless HTTP run reportedly leaves 9 after 9 calls (https://github.com/google/adk-python/issues/7154). A collaborator reran the script on current main and got the same 10 leaked sessions (https://github.com/google/adk-python/issues/7154#issuecomment-5725844137). Later the collaborator said nothing under mcp_tool calls delete_session through v2.11.0 and _agent_to_mcp.py is unchanged, so the leak remains in every release (https://github.com/google/adk-python/issues/7154#issuecomment-6018483628, https://github.com/google/adk-python/issues/7154#issuecomment-6044504340). The default runner uses InMemorySessionService, a plain dict with no eviction, so the growth is unbounded in the default setup. Proposed fix status: PR #7155 is only proposed. As described in the comments, it tracks created session ids and reaps orphaned ones in a background task, using a bounded worker pool, delete timeouts, and cancellation-safe re-tracking, with a delete_orphaned_sessions option (default True; False disables it) (https://github.com/google/adk-python/issues/7154#issuecomment-5726990570, https://github.com/google/adk-python/issues/7154#issuecomment-5830509575, https://github.com/google/adk-python/issues/7154#issuecomment-5909925973). A collaborator reports that on merged-main runs it leaves about 1 session after the repro and drains to 0 under slow-delete load (https://github.com/google/adk-python/issues/7154#issuecomment-6018483628). The last supplied comment says it awaits review by @wukath and that CI workflows need approval; no merge or release is shown. Caveats: reaping changes behavior for persistent caller-supplied session services, since conversations would no longer remain readable after the connection dies; the PR docstring reportedly notes pre-restart orphans are not reaped. Stateless mode also yields single-turn conversations per call, as the issue notes. Limitation: these are external reports and collaborator checks, with no KFA reproduction. Diagnosis is limited to checking whether session counts grow per connection or call; no released fix exists.