Memory leak: McpSessionHandler objects never disposed on session end — 10,450 stale sessions consuming 3.4 GB

## Summary

The JetBrains built-in MCP server (`com.intellij.mcpserver`) accumulates `McpSessionHandler` objects indefinitely. When MCP clients connect and disconnect — as happens continuously when AI coding tools (Claude Code, Codex, Cursor) run — each session creates a `McpSessionHandler` that is never garbage-collected. After a day of normal multi-agent use, 10,450 stale sessions consume **3.4 GB of heap**, causing repeated `OutOfMemoryError` and IDE freezes.

## Evidence — heap histogram (from a live heap before OOM)

Captured via `jcmd GC.class_histogram` while IntelliJ was frozen with 29 MB free of 6144 MB:

```
num #instances #bytes class name
------------------------------------------------
12: 1,525,773 48,824,736 com.intellij.mcpserver.McpToolSchema
14: 449,350 39,542,800 com.intellij.mcpserver.impl.McpSessionHandler$mcpToolToRegisteredTool$1
16: 898,700 35,946,800 com.intellij.mcpserver.McpToolDescriptor
19: 898,700 21,568,800 com.intellij.mcpserver.impl.ReflectionCallableMcpTool
20: 898,700 21,568,800 com.intellij.mcpserver.impl.util.CallableBridge
109: 10,453 668,992 com.intellij.mcpserver.impl.McpSessionHandler
170: 10,453 418,120 com.intellij.mcpserver.impl.McpSessionHandler$createAndInitializeSession$3
```

**Key calculation:**
- 10,453 `McpSessionHandler` instances alive (should be ~0–5 at any given time)
- 449,350 `RegisteredTool` instances ÷ 10,453 sessions = **43 tools registered per session** — matching the built-in MCP tool count exactly
- 1,525,773 `McpToolSchema` objects at 48 MB
- Estimated retained heap from accumulated sessions: **~3.4 GB**

By contrast, the third-party index-MCP plugin (`com.github.hechtcarmel.*`) had only **473 small objects** in the same heap — confirming the leak is entirely in `com.intellij.mcpserver`.

## Root cause

`McpSessionHandler` objects are created per session but not properly disposed when sessions end. The MCP Kotlin SDK session registry holds strong references to them. With AI coding tools creating and reconnecting sessions continuously (50+ Claude processes across a working day produces thousands of connect/disconnect events), the accumulation is rapid and unbounded.

This is the same class of disposer bug previously reported in [#3 (FindCommitByTextTool disposable leak)](https://github.com/JetBrains/mcp-server-plugin/issues/3).

## Impact

- OOM crash / IDE freeze after ~8 hours of normal multi-agent use
- Affects any user running multiple AI coding tool sessions simultaneously (Claude Code, Codex, Cursor, Windsurf)
- Workaround: disable the built-in MCP Server plugin entirely (Settings → Plugins → MCP Server → uncheck); restart IntelliJ — recovers 3.4 GB immediately

## Environment

- IntelliJ IDEA 2025.3 (IU-261.24374.151)
- macOS, Apple Silicon
- 6 GB JVM heap (`-Xmx6144m`)
- Multiple Claude Code sessions connected simultaneously

## Suggested fix

Ensure `McpSessionHandler` implements `Disposable` and is registered with the session's lifecycle disposable (not `ROOT_DISPOSABLE`), so it is disposed when the HTTP/SSE connection closes. The session registry should hold weak or soft references, or actively remove entries on disconnect.

Start at com.intellij.mcpserver.impl.McpSessionHandler and trace how the MCP Kotlin SDK session registry handles HTTP/SSE disconnects. Check the session lifecycle and disposal path, then verify that handlers and their registered tools are released after sessions end. Done means repeated connect/disconnect cycles no longer retain stale handlers or cause unbounded heap growth.

Written by the indexing model from the issue text.