[Bug] wait_agent 阻塞期间用户消息静默排队 26 分钟，无提示也无法让路

[alaemiryoung]

会话在 turn 16 step 18 调用 wait_agent，参数 timeout_ms=3000000。六分钟后用户在界面上发了一条消息，界面没有任何回应；实际要等到 06:32:55 这个工具返回、step 结束，消息才被消费，06:33:06 才得到回复。排队时长 25 分 48 秒，工具实际阻塞 29 分 13 秒。

日志证据（session-38c33164）：

06:03:42  tool/call     wait_agent  timeout_ms=3000000
06:07:05  inbox/spliced next-turn  +1
06:07:07  inbox/spliced next-turn -1 / next-step +1
06:32:55  tool/result   wait_agent 返回
06:32:55  step/end → step/start → user/message
06:33:06  assistant 回复

机制上，inbox 的 next-step 只在 step 边界被 claim，而工具执行期间没有任何消费者；dsh-tools 里也没有 inbox 或 steer 的联动，工具不会因为用户来了新指令而让路。唯一的打断方式是 cancel 整个 turn，粒度太粗，而且当前 UI 没有「只中断当前工具」的入口。

影响是用户对正在等待的 agent 说话得不到任何反馈，且看不到「消息已排队」的任何提示。wait_agent 允许单次阻塞 1 小时，这意味着最坏情况下用户要等一小时。

对照 Codex：本机 Codex CLI 里有 edit_queued_message、Queued messages run now、ActiveTurnNotSteerable、「Model interrupted to submit steer instructions.」，以及提示词里明确写 Running backend work remains steerable。也就是说 Codex 把运行中的用户消息当作可见、可编辑、可立即执行的队列项，并且会为了投递 steer 指令打断当前模型。这不是平台差异，是能力差异。

建议三件事。长阻塞工具（wait_agent 等）应声明可让路，收到 next-step 输入时提前返回控制权；或者 agent-loop 在工具执行期间监听 inbox，出现 next-step 输入时 abort 当前工具但保留本轮上下文；UI 至少要把排队状态显示出来并给一个「立即发送」入口。另外建议收紧 wait_agent 的 timeout 上限，长等待交给外层循环重试，避免单步阻塞几十分钟。