fix(tui): start MCP discovery for websocket sessions

[sweetcornna]

Summary

• start shared background MCP discovery for TUI WebSocket sessions before gateway.ready
• make TUI agent construction wait on the shared MCP startup state instead of the stdio-only entry module state
• reuse the same MCP startup helper from stdio TUI and WebSocket TUI paths

Root cause

The stdio TUI path started MCP discovery inside tui_gateway.entry.main(), but Desktop/dashboard WebSocket sessions enter through tui_gateway.ws.handle_ws() and never execute that startup path. _make_agent() also waited on tui_gateway.entry.wait_for_mcp_discovery(), so WebSocket-created agents had no discovery thread to wait for before snapshotting tools. Manual /reload-mcp worked because it explicitly re-ran discovery and refreshed the session's tool list.

Scope

This addresses the Desktop/WebSocket startup-discovery half of #37589 and the duplicate report #38271. It intentionally does not include the separate uvx/GUI PATH fallback from #37589; that should be a smaller follow-up if still needed.

Validation

• .venv\\Scripts\\python.exe -m pytest tests/tui_gateway/test_mcp_discovery_startup.py tests/tui_gateway/test_wait_for_mcp_discovery.py tests/test_tui_gateway_server.py::test_make_agent_waits_for_shared_mcp_discovery_before_tool_snapshot tests/hermes_cli/test_mcp_startup.py -q --timeout-method=thread -> 10 passed
• .venv\\Scripts\\python.exe -m ruff check tui_gateway/entry.py tui_gateway/server.py tui_gateway/ws.py tests/tui_gateway/test_mcp_discovery_startup.py tests/tui_gateway/test_wait_for_mcp_discovery.py tests/test_tui_gateway_server.py -> All checks passed!
• .venv\\Scripts\\python.exe -m py_compile tui_gateway/entry.py tui_gateway/server.py tui_gateway/ws.py hermes_cli/mcp_startup.py -> passed
• git diff --check -> passed

Addresses #37589
Addresses #38271

[teknium1]

Merged via #54161 (commit 5c2c85c on main) — your handle_ws discovery fix was cherry-picked with your authorship preserved in git log. You were the earliest of the cluster to spot that the WS sidecar (tui_gateway/ws.py) never starts MCP discovery, so the desktop/dashboard agent snapshots an MCP-less tool list. The rest of this PR (migrating the discovery thread slot from entry.py → hermes_cli/mcp_startup.py) had already landed on main, so only the ws.py start call remained relevant. Thanks!

#54161