fix(mcp): increase MCP discovery timeout for kanban workers

[liuhao1024]

What does this PR do?

Increases the MCP discovery wait timeout for kanban workers from 0.75s to 60s so that slow MCP servers (30s+ to initialize) have time to register their tools before the worker agent makes its first API call.

Related Issue

Fixes #43273

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• hermes_cli/mcp_startup.py: In wait_for_mcp_discovery(), detect kanban worker context (via HERMES_KANBAN_TASK env var) and use max(timeout, 60.0) instead of the default 0.75s timeout. Kanban workers are background subprocesses that depend on MCP tools for task execution — a longer blocking wait is acceptable.
• tests/hermes_cli/test_mcp_startup.py: Add 3 regression tests covering kanban worker timeout escalation, explicit timeout preservation (>60s passed through), and non-kanban sessions using the caller-provided timeout unchanged.

How to Test

1. Configure an MCP server that takes 30+ seconds to initialize (e.g., chrome-devtools-win via stdio/npx)
2. Create a kanban task that requires MCP tools
3. Dispatch the task: hermes kanban dispatch
4. Before this fix: first API call fires before MCP tools are registered (0.75s wait)
5. After this fix: worker waits up to 60s for MCP discovery to complete

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/hermes_cli/test_mcp_startup.py -v and all tests pass (7/7)
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Code Intelligence

• Analyzed: wait_for_mcp_discovery (callers: 2 in cli.py, 1 in tui_gateway/server.py)
• Blast radius: LOW — only affects the wait timeout for MCP discovery; no control flow changes
• Related patterns: HERMES_KANBAN_TASK env var is the standard kanban worker context signal (used in cli.py at lines 15622, 15925, 15967, 16135)

[teknium1]

Thanks for addressing a real kanban/MCP startup race. The issue remains on current main: worker initialization calls wait_for_mcp_discovery() at hermes_cli/cli_agent_setup_mixin.py:237-239, and the default bounded wait is only 1.5 seconds (hermes_cli/config.py:1359-1372), so the reported 34-second server still misses the first tool snapshot.

Problems

• The diff targets the pre-refactor wait_for_mcp_discovery(timeout=0.75) implementation. Current main resolves explicit/configured bounds through _resolve_discovery_timeout() in hermes_cli/mcp_startup.py:53-71; the added max(timeout, 60.0) needs to be integrated after that resolution rather than restoring the old timeout contract.
• The added tests cover only the old direct argument path. They do not exercise the current config-backed resolution or the worker agent-build caller.

Suggested changes

• Preserve the current config resolver, then apply the worker-specific 60-second minimum.
• Add regression coverage for worker/non-worker resolution against the current implementation and, if practical, the first agent-build snapshot path.

Automated hermes-sweeper review.

[teknium1]

Current main no longer has this fixed timeout=0.75 contract: wait_for_mcp_discovery() resolves mcp_discovery_timeout through _resolve_discovery_timeout(). Please integrate the kanban minimum after that resolver so configured bounds and the current API are retained.