fix(mcp): reconnect message-less closed transports

[diffen77]

Summary

• recognize message-less AnyIO ClosedResourceError, BrokenResourceError, and EndOfStream failures (including nested exception groups) as stale MCP transports
• preserve interruption precedence, rebuild the existing server-owned transport, wait for a distinct ready session, and retry the interrupted operation once
• reset both circuit-breaker count and open timestamp after successful recovery without rebuilding registered handlers or tool schemas
• exercise the real MCPServerTask.run() lifecycle for both stdio and Streamable HTTP configurations

This is a follow-up to #13383: the existing text-based recovery handles explicit "expired session" responses, but AnyIO transport-close exceptions are commonly message-less and therefore bypassed that classifier.

Verification

• scripts/run_tests.sh tests/tools/test_mcp_tool_session_expired.py tests/tools/test_mcp_circuit_breaker.py tests/tools/test_mcp_reconnect_signal.py tests/tools/test_mcp_reconnect_retry_reset.py -j 4 — 37 passed
• scripts/run_tests.sh -j 8 <all tests/tools/test_mcp*.py + test_refresh_agent_mcp_tools.py + tests/tui_gateway/*.py + tests/test_tui_gateway*.py + test_tui_mcp_late_refresh.py> — 77 files, 1426 passed
• ruff check . — passed
• git diff --check — passed
• operational stdio smoke: a real FastMCP child intentionally exited during the first call; the already-registered handler transparently returned from a fresh session on the single retry, with the same registry entry, handler identity, and schema, and breaker count reset to zero

Recovery contract reviewed

• bounded reconnect lifecycle/backoff remains unchanged
• per-server RPC lock and reconnect event preserve serialized/single-flight behavior
• exactly one handler retry is attempted
• cancellation/interruption is never reclassified as transport expiry
• tool registration/schema identity remains stable across reconnect

[alt-glitch]

This was generated by AI during triage.

Related to #65111: both address closed MCP transports, while this PR additionally handles nested AnyIO exception groups and reconnect lifecycle/breaker reset behavior. The overlapping recovery paths need maintainer consolidation.

[teknium1]

Thanks for covering the message-less AnyIO path. Current main still rejects empty exception text in tools/mcp_tool.py:3553-3562, while the handler reaches session recovery through tools/mcp_tool.py:4299-4304, so the premise is valid.

Problems

• tools/mcp_tool.py:3587 recursively classifies nested exceptions without the cycle/depth guard used by the new interruption helper. The new cycle test only exercises _exception_tree_contains_interruption (tests/tools/test_mcp_tool_session_expired.py:142-154), so a cyclic or deeply nested .exceptions graph can still recurse during classification.
• This overlaps with #65111, as the maintainer comment notes. Its proposed classifier also covers BrokenPipeError and EOFError; consolidate the transport-type coverage rather than retaining parallel recovery classifiers.

Suggested changes

• Use one iterative, identity-tracked exception-tree traversal for interruption precedence and transport-leaf detection; add classifier-level deep/cyclic tests.
• Fold in #65111's built-in pipe/EOF coverage while preserving the existing text fallback and one-retry contract.

Automated hermes-sweeper review.

[teknium1]

This recursive walk does not share the cycle/depth protection added in _exception_tree_contains_interruption. A cyclic or deeply nested .exceptions graph can recurse here before classification; traverse the exception graph iteratively with an identity-based visited set, and add a classifier-level regression test.

[teknium1]

Merged via #68660. Your message-less closed-transport classification was cherry-picked (4 commits, authorship preserved); we made the cause/context traversal cycle-guarded on top.