fix(tui-gateway): start MCP discovery for websocket sessions

[LionGateOS]

Summary

Starts background MCP tool discovery for WebSocket/Desktop gateway sessions before emitting gateway.ready.

Previously, tui_gateway.entry.main() started MCP discovery for the stdio/TUI path, and _make_agent() briefly waited for that discovery before snapshotting tools. WebSocket/Desktop sessions enter through tui_gateway.ws.handle_ws() and do not run entry.main(), so MCP discovery could be skipped before the first agent build.

This refactors the existing MCP startup logic into ensure_mcp_discovery_started() and calls it from both:

• tui_gateway.entry.main() for stdio/TUI
• tui_gateway.ws.handle_ws() for WebSocket/Desktop

Motivation

Desktop/Dashboard sessions should discover configured MCP tools the same way TUI sessions do. Without this, MCP tools can be missing from Desktop sessions even when they are configured.

Testing

• uv run --extra dev python -m pytest tests/test_tui_gateway_ws.py tests/tui_gateway/test_wait_for_mcp_discovery.py

[alt-glitch]

Likely duplicate of #38301 — same root cause and the same fix. Consolidating there; flagging for maintainer review.

[LionGateOS]

Thanks for checking. That makes sense — I’m fine with consolidating into #38301 if that is the preferred PR.

For reference, this PR was tested with:

uv run --extra dev python -m pytest tests/test_tui_gateway_ws.py tests/tui_gateway/test_wait_for_mcp_discovery.py

The local result was 7 passed. If useful, the focused WebSocket test coverage from this branch can be compared against #38301 before closing/merging.

[teknium1]

Fixed via #54161 (commit 5c2c85c on main). This was a duplicate of #38301 (@sweetcornna, submitted first) — both fixed the same site: tui_gateway/ws.py::handle_ws never started background MCP discovery, so the desktop app and dashboard chat built the agent with no MCP tools. Credit to @sweetcornna as the earliest submitter; thanks for the independent fix here too.

#54161