Soft-fail slow MCP discovery at startup

[LeonSGP43]

Fixes #29726

Summary

• add an optional startup timeout for MCP discovery and let timed-out discovery continue on the MCP background loop
• use a short bounded wait during CLI and gateway startup so slow optional MCP servers do not block Hermes boot
• cover the soft-fail startup path with a targeted MCP discovery test

Testing

• uv run --frozen pytest -q -o addopts= tests/tools/test_mcp_tool.py -k 'startup_soft_fail or failed_count'\n- uv run --frozen ruff check tools/mcp_tool.py hermes_cli/main.py gateway/run.py tests/tools/test_mcp_tool.py\n- git diff --check

[teknium1]

Thanks for targeting optional MCP startup latency. Current main has already adopted a newer background-discovery design for CLI/TUI startup, but the gateway remains a live gap.

Problems

• The patch cannot be transplanted unchanged: current tools/mcp_tool.py:4996 defines discover_mcp_tools() without startup_timeout or continue_in_background; those call sites have been superseded by hermes_cli/mcp_startup.py:27-100.
• The remaining current-main gateway path is still blocking: gateway/run.py:20793 awaits discovery, and discovery performs the 120-second outer wait at tools/mcp_tool.py:4974. The proposed test only covers the obsolete lower-level API, not this production gateway path.

Suggested changes

• Re-scope the salvage to gateway/run.py:20784-20798, integrating with the current background-discovery/snapshot-refresh design rather than reintroducing the old timeout API.
• Add a gateway-startup regression test proving runner.start() is reached while discovery remains blocked, plus coverage for safe late tool availability.

Automated hermes-sweeper review.

[kshitijk4poor]

Closing in favor of #75985 (merged), which resolves #29726 for the last remaining synchronous startup surface (ACP).

Since this PR was opened, main replaced the startup discovery design your patch extends: discover_mcp_tools() no longer takes startup-timeout kwargs — CLI/TUI/gateway-adjacent surfaces now use hermes_cli/mcp_startup.py (background daemon + bounded wait_for_mcp_discovery + between-turns snapshot refresh), landed in 0c6e133 / 93d6e73 / 3572d4b. That superseded the startup_timeout / continue_in_background API this PR adds, so there was no longer a transplantable diff.

Your diagnosis of the problem (bounded wait + continue in background) was right and is exactly the shape the shipped design uses. Thanks for the contribution.