Fix #29726 — One unhealthy optional MCP integration should not make the whole Hermes session unavailable

Problem

When an MCP server is configured under mcp_servers, Hermes attempts to connect and discover tools during startup. If that MCP server is down, slow, misconfigured, or fails during initialize / list_tools, Hermes startup could hang indefinitely before the normal chat session becomes usable.

Root Cause

The MCPServerTask.start() method called await self._ready.wait() with no timeout wrapper. If the server's internal run() loop never fires _ready.set() (e.g., due to a silently swallowed exception in a nested transport handler), start() blocks forever — and since MCP discovery runs serially per-server, one dead server freezes the entire startup.

Fix

1. MCPServerTask.start() — wrapped await self._ready.wait() in asyncio.wait_for(timeout=connect_timeout). On timeout: cancels the orphaned run-task to prevent resource leaks, then raises TimeoutError.
2. hermes_cli/main.py — changed MCP startup error log from logger.debug → logger.warning so users see a clear "MCP tool discovery failed" message instead of silently losing tools.

Behavior Change

• Before: A hung/stuck MCP server could block Hermes startup indefinitely.
• After: Per-server connection timeout (default 60s, configurable via connect_timeout) limits wait time. Failed servers log a visible warning. The rest of Hermes starts normally with available servers only.

Notes

• No breaking API changes. All existing MCP configs work identically.
• discover_mcp_tools() already used asyncio.gather(return_exceptions=True) and logged warnings for per-server failures — this just adds the missing timeout guard at the lowest level (start()).