[Bug] MCP 版本协商探测固定 5s 超时且不重试，用户配置 timeoutMs 不生效，远程 MCP 工具间歇性整会话丢失

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

工具调用 / MCP · Tool use / MCP

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

严重程度 · Severity

影响体验 · Major (功能可用但体验受损 / works but degraded)

复现频率 · Reproducibility

偶现 · Sometimes

问题描述 · Description

会话启动时，远程 HTTP MCP 服务器会随机整批失败，报 Version negotiation probe timed out after 5000ms。失败的服务器在该会话内所有工具都不注册，且整个会话无法恢复，只能重开会话碰运气。

复现步骤 · Steps to reproduce

1. 在 ~/.zcode/cli/config.json 的 mcp.servers 下配置多个远程 HTTP MCP 服务器（实测：context7、tavily、trilium、自建 hindsight 共 4 个启用项），其中 hindsight 配置 "timeoutMs": 120000；
2. 正常网络环境下反复新建会话（当天实测十余次）；
3. 查看每次会话的启动日志 ~/.zcode/cli/log/zcode-YYYY-MM-DD.jsonl 中的 mcp.server.failed / mcp.startup.completed / mcp.tools.registered 事件，并对比会话内实际可用的 MCP 工具数量。

期望表现 · Expected behavior

1. 版本协商探测超时遵循该服务器配置的 timeoutMs（配 120s 就应有 120s 探测窗口），或至少采用远大于 5s 的上限；
2. 探测超时后自动重试若干次（≥2 次）再判失败；
3. 每次会话所有启用的服务器都连接成功、工具完整注册（健康会话 registeredToolCount=100）；
4. 个别服务器启动失败时提供会话内恢复手段（重连并补注册工具），而不是把失败绑定到整个会话生命周期。

实际表现 · Actual behavior

1. 启动瞬间探测超过 5s 的远程服务器整批判死：mcp.server.failed … Version negotiation probe timed out after 5000ms（中招会话中 5 个服务器全部如此）；
2. 失败服务器在整个会话内工具缺失：mcp.tools.registered {registeredToolCount: 33}（健康会话为 100），会话内无任何恢复手段，只能重开会话碰运气；实测约 1/3 会话中招；
3. 用户配置的 "timeoutMs": 120000 完全不生效——报错恒为 5000ms（实际探测超时 = min(写死的 5s 上限, timeoutMs/2)）；且失败后零重试（probe.maxRetries ?? 0 恒为 0）；
4. 同一服务器在相邻会话中 628ms 即连接成功，证明是启动瞬间的网络抖动 × 硬编码 5s 超时 × 零重试三者叠加，并非服务器不可达。

ZCode 版本 · ZCode version

ZCode 桌面版 Windows x64（内置 glm 运行时，MCP client: zcode 0.16.5）

设备 / 系统 / 浏览器 · Device / OS / Browser

Windows 10 x64

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

No response

Start with the MCP startup path represented by the mcp.server.failed, mcp.startup.completed, and mcp.tools.registered log events, using the config at ~/.zcode/cli/config.json as the timeout input. Compare failed and healthy sessions in the JSONL logs; done means configured timeouts are honored, retries occur, and failed servers can recover with complete tool registration.