[Bug] user_prompt_hooks 阶段阻塞首 token 最长 120s：钩子排队无全局硬上限，同进程长会话饿死新会话回合前置（3.14.1/Windows） #828

问题描述

发送消息后，从「回合开始」到「模型请求真正发出」之间存在长时间静默阻塞（实测 5~126 秒），期间界面只显示"工作中"，模型没有开始推理。根因指向 user_prompt_hooks 阶段的串行阻塞 + 单一 host 进程内多会话互相拖累。

日志证据（cli/log 日卷 JSONL，2026-09-26~27，已脱敏）

1. 回合阶段计时：turn.phase.completed phase=user_prompt_hooks 的 durationMs 分布为 1807 / 5291 / 5384 / 5498 / 5600 / 5733 / 5923 / 5982 / 6807 / 7365 / 8530 / 9381 / 10975 / 22362 / 31698 / 125993 ms——同一台机器、同一个钩子配置，耗时相差 70 倍。
2. 注册的 UserPromptSubmit 钩子本身极轻：单独计时仅 83ms（Git Bash 冷启动 + printf + date）。即 22 秒不是钩子逻辑耗时，而是钩子阶段排队/调度被卡。
3. 插件钩子触顶失败：hook.run.failed（PreToolUse，某安全插件）durationMs=120026/120024/120019/120026/120035/120026，即插件钩子挂满 120 秒超时上限才失败；hook.run.failed（UserPromptSubmit）durationMs=30032 / 120681。一个挂起的插件钩子会让所在回合干等到超时。
4. 跨会话拖累：本次新会话 turn 0 的 user_prompt_hooks 耗时 22362ms，同一时刻同一 host 进程内另一会话（1530 条消息的长会话）正在流式处理其模型请求（RSS ~708MB）。新会话的钩子阶段与长会话的序列化/流式处理共享同一事件循环，被明显饿死。

期望

• 钩子阶段设全局硬上限（如 5 秒），超限跳过并显式提示"某钩子超时已跳过"，而不是阻塞首 token 到 120 秒。
• 插件钩子超时上限从 120 秒大幅收紧，且在 UI 显示当前正在执行哪个钩子。
• 评估会话间隔离：长会话（数百条消息、大上下文序列化）流式处理时，不应饿死同进程新会话的回合前置阶段。

影响

用户感知为"发消息后半天不开始思考"，且完全无提示、无诊断入口，容易误判为软件卡死。