fix: suppress RuntimeError in MCP task shutdown when event loop is closed

[shaiful-hisham]

Problem

When exiting Hermes, MCP server tasks that are still pending can encounter an already-closed event loop during cancellation. Calling t.cancel() after the loop is closed raises RuntimeError('Event loop is closed'), which surfaces as Exception ignored in: <coroutine object MCPServerTask.run> during garbage collection.

Symptom

Exception ignored in: <coroutine object MCPServerTask.run at 0x10d3f5d20>
RuntimeError: Event loop is closed

Fix (4 call sites in tools/mcp_tool.py)

1. _wait_for_lifecycle_event finally — wrap t.cancel() in try/except RuntimeError so cancelled tasks clean up silently when the loop is already gone
2. _wait_for_reconnect_or_shutdown finally — same pattern
3. _wait_for_lazy_reconnect finally — same pattern
4. _stop_mcp_loop drain path — change elif not loop.is_closed() to if not stop_owned_by_loop and not loop.is_closed() so drain is always attempted regardless of schedule success

Tested

Verified on macOS — the "Exception ignored" traceback no longer appears on hermes exit.

Consolidation

This PR is the consolidated fix for the closed-loop cancellation family, superseding #60032, #60104, and #60380. Coverage comparison:

Call site	This PR	#60032	#60104	#60380
_wait_for_lifecycle_event finally	✅	✅	❌	❌
_wait_for_reconnect_or_shutdown finally	✅	✅	❌	❌
_wait_for_lazy_reconnect finally	✅	❌	❌	❌
_stop_mcp_loop drain path	✅	❌	❌	❌

This PR fixes the whole bug class — every finally block that calls t.cancel() on a possibly-closed loop, plus the drain path in _stop_mcp_loop so tasks are always cancelled before loop.close(). Happy to coordinate with #60032's author (open) so we land one shared shutdown strategy rather than overlapping fixes.

[alt-glitch]

This was generated by AI during triage.

Related to #60032, #60104, and #60380: this uses the same closed-loop cancellation family but adds lazy-reconnect coverage and a drain-path change. Please consolidate the preferred shutdown strategy.

[shaiful-hisham]

Thanks for the triage note. I've updated the PR description with a Consolidation section — this PR is intentionally the consolidated fix for the closed-loop cancellation family:

• Covers all 4 call sites: the two in fix(mcp): catch RuntimeError when cancelling tasks on a closed event loop #60032 (_wait_for_lifecycle_event, _wait_for_reconnect_or_shutdown) plus _wait_for_lazy_reconnect and the _stop_mcp_loop drain-path change.
• Superset of fix(mcp): catch RuntimeError when cancelling tasks on a closed event loop #60032 (open), fix(mcp): drain parked tasks before closing loop #60104, fix(mcp): suppress 'Event loop is closed' traceback flood at shutdown #60380.

Happy to coordinate with the #60032 author so we land one shared shutdown strategy rather than overlapping fixes — this PR is ready to serve as the consolidation point.