fix(dashboard): avoid eager MCP discovery at startup

[lesterlxt]

What does this PR do?

Stops hermes dashboard / hermes serve from starting MCP discovery eagerly during process startup. MCP discovery remains available through the real Desktop/Dashboard chat path and begins lazily when /api/ws accepts a connection.

This avoids launching configured MCP server processes when a user only opens the Dashboard for non-chat UI, while preserving MCP tools for actual Dashboard and Desktop conversations.

Related Issue

Fixes #60572.

Type of Change

• Bug fix
• Startup/lifecycle fix
• Tests

Root Cause and Intent

Dashboard-level discovery was added before the WebSocket sidecar had its own startup hook. Current main now has both paths:

1. cmd_dashboard() starts dashboard-mcp-discovery immediately.
2. tui_gateway.ws.handle_ws() starts the shared, idempotent discovery after a real chat WebSocket is accepted and before gateway.ready.

The second path is the correct lifecycle boundary. _make_agent() already performs a bounded wait before taking its first tool snapshot, and the existing late-refresh path handles slow MCP servers before the first turn. Removing the process-start call therefore avoids eager work without removing MCP from Desktop or Dashboard chat.

The shared guard is process-local, so it prevents two discovery threads inside one Dashboard process but cannot prevent a separate gateway process and an otherwise-idle Dashboard process from each launching their own MCP servers. Deferring Dashboard discovery until chat is actually used addresses that case without disabling the chat feature.

Changes Made

• Remove eager start_background_mcp_discovery() from cmd_dashboard().
• Update the Dashboard startup regression to require zero MCP discovery calls, including with --open-profile.
• Preserve the existing /api/ws regression that starts discovery after WebSocket acceptance.
• Update mcp_startup.py lifecycle documentation so it no longer lists hermes dashboard as a direct startup caller.

How to Test

scripts/run_tests.sh \
  tests/hermes_cli/test_dashboard_unified_launch.py \
  tests/test_tui_gateway_ws.py \
  tests/hermes_cli/test_mcp_startup.py \
  tests/hermes_cli/test_dashboard_web_dist_validation.py \
  tests/test_tui_gateway_server.py -- -q

Validation after rebasing onto current main (659d1123c):

• Relevant suites: 361 passed, 0 failed.
• Ruff: passed.
• git diff --check: clean.
• Fix-forward proof: applying the final Dashboard regression to the unfixed current main produces the expected failure because cmd_dashboard() calls dashboard-mcp-discovery; the rebased fix removes that call.

Behavior Contract

Dashboard/serve process starts  -> no MCP discovery
Real /api/ws chat connects      -> shared MCP discovery starts
First agent is built            -> bounded wait + late refresh preserve tools

Risk Assessment

Low. The change removes one obsolete caller and retains the tested WebSocket caller, bounded agent wait, late refresh, and process-wide idempotence. No tool schema or mid-conversation toolset changes are introduced.

[alt-glitch]

This was generated by AI during triage.

Competing fix for #60572 (dashboard over-spawns MCP servers). Two OPEN PRs, different mechanisms:

• fix(dashboard): avoid eager MCP discovery at startup #60602 (this) removes the eager start_background_mcp_discovery() block from cmd_dashboard in hermes_cli/main.py, leaving discovery lazy on the /api/ws chat path.
• fix(tui_gateway): skip MCP discovery in dashboard mode #60592 gates the WS-sidecar discovery on HERMES_SERVE_HEADLESS=1 in tui_gateway/ws.py so hermes serve still discovers but hermes dashboard skips it.

Related, not duplicate. Flagging for a maintainer to pick the preferred approach.

[teknium1]

Thanks for the focused fix. The premise remains present on current main: cmd_dashboard eagerly calls start_background_mcp_discovery() at hermes_cli/main.py:12157-12163. Current main already preserves the required lazy path: dashboard /api/ws dispatches to tui_gateway.ws.handle_ws (hermes_cli/web_server.py:15515-15531), which starts discovery after connection acceptance at tui_gateway/ws.py:312-317; that behavior is covered by tests/test_tui_gateway_ws.py:10-42.

The PR's deletion therefore removes the startup-side duplicate without removing MCP discovery for actual dashboard or desktop chat sessions. The updated dashboard regression is aligned with that contract.

Automated hermes-sweeper review.

[lesterlxt]

Rebased onto current main and revalidated the Dashboard/WebSocket MCP lifecycle. I also updated the stale lifecycle documentation to reflect that discovery is now initiated by the chat WebSocket rather than Dashboard startup.

• 361 related tests pass
• Ruff and git diff --check pass
• The final regression test fails as expected on unfixed current main

Ready for review.