超时横幅上的「重试」点了没反应——独立排查（#3367 的前提已被证伪，不能挂在它下面）

## 现象（人类实测，2026-09-10，devapp）

超时横幅「这次执行超时了，还没有等到结果」旁的**「重试」按钮点了没有任何反应**。原始记录在 #3317 的追加评论（`issuecomment-5613527186`）。

## 为什么单独立项

原先把它挂在 #3367 下，前提是「run 被吞掉的错误卡在 `running`，所以重试被拒」。**那个前提已被真栈实测证伪**（见 #3367 的协调裁决评论）：执行器自己会落终态，且没有一支 catch 适合 `failRun`。

因此「重试为什么没反应」**必须独立排查**，不能沿用那条已作废的解释。

## 需要分开取证（不许合并结论）

1. 点击**有没有发出请求**？（网络面板 / 服务端访问日志逐条看）
2. 发了但**服务端拒绝或静默失败**？——注意 #3367 查明的三类处置：那一轮的 run 可能 (a) 根本不存在、(b) 仍在活着被执行器持有、(c) 停在 `awaiting_tool_permission` 等人批。**三种情况下「重试」的正确语义各不相同**，先判是哪一种。
3. 请求成功了但**前端没有任何反馈**（新 run 起了却不渲染 / 横幅不消失）？

## 要求

- **判据必须落在「点击之后真的重新跑起来了」**，不能只判「触发了 onClick」或「发出了请求」——那种断言在本缺陷下无法被证伪。#3311 已有先例：判据被要求是「点击后用户真的到达了可以授权的地方」。
- **三步反证**：造出缺陷形状 → 断言变红并贴真实输出 → 撤掉 → 恢复绿。**只贴绿不算数**（本仓已九次「全绿但空转」）。
- 若查明在某些终态下「重试」本就不该存在，那也要**显式处理**：要么按钮不出现，要么点了给出明确说明——**不允许存在一个可点但什么都不做的按钮**。
- 若根因与 #3367 采纳的第 3 类（run 仍在等审批却被译成「出错」）重合，**说明重合处并与那条线对齐**，不要各改各的。

## 相关

#3317（502 / 超时的传输层成因，仍在排查）、#3367（RUN_ERROR 的三类处置）、#3311（点通知等于读掉并丢弃，同族）。

Reproduce the timeout banner in devapp, then inspect the network panel and server access logs after clicking Retry to distinguish the three cases described in the issue. Read the linked discussions in #3367, #3317, and #3311 before choosing the behavior. Done means a real rerun is observable, or every terminal state gives explicit feedback, with a regression test that goes red when removed and green when restored.

Written by the indexing model from the issue text.