qa: TW-P0-3④ 确认门 e2e 恒红——替身与读模型都已排除，缺口在 interrupted → awaiting_tool_permission 这一段

判决 run `34293903801`（job `chat-task-workbench`，headSha `724ff4d9e`）里
`chat-task-workbench-workflow-states.spec.ts` 三条红，逐条停在**第一个锚点**上：

| 用例 | 失败行 | 失败锚点 | 分类 |
|---|---|---|---|
| `:87` ②③ | `:92` | `chat-task-workbench-plan-panel` | 没跑到断言（60s 锚不到） |
| `:143` ④ | `:157` | `chat-task-workbench-plan-confirm` | 没跑到断言（60s 锚不到） |
| `:238` ⑤ | `:243` | `chat-task-workbench-run-progress` | 没跑到断言（60s 锚不到） |

`:87` / `:238` 的两处已在 PR（见下）里修掉。**本 issue 只留 `:143` 那条**——
它不在前端，前端从头到尾拿到的账本是 `phase:"preparing" / runStatus:"running" /
steps:0 / gate:{required:false,reason:"no-plan"}`（trace 里 44 次 `/plan-control/.../ledger`
只出现两种响应体，另一种是 run 起来之前的 `preparing/idle`）。

## 已排除

- **替身不是嫌疑人。** 本机单独起 `loopback-deep-agent-provider.ts` 打真实协议：
`POST /threads/:id/runs` → `/stream` 正常 EOF → `GET .../runs/:runId` 回
`{"status":"interrupted"}` → `GET /threads/:id/state` 里是一条**未配对**的
`write_todos`，args `{todos:[3 条 pending]}`。形状与 `derivePlanPhase` /
`parseProposedSteps` 期望的逐字一致。
- **契约与读模型不是嫌疑人。** `derivePlanPhase` 的 `hasPendingPlanConfirmation`
分支排在 `ledgerEmpty` 之前；`get-plan-ledger.ts` 在 `pendingToolName ===
PLAN_CONFIRMATION_TOOL_NAME` 时用提案步骤顶替空账本（所以 `steps` 会是 3，
不是 0）；`pg-plan-ledger-repository.ts` 的两列同生同灭门也对。
- **前端渲染门不是嫌疑人。** `PlanConfirmGate` 只受 `phase === "planning" &&
gate.required` 控制，不受折叠态影响；`steps.length === 0 && runLive` 那条
#3099 早退分支在提案路径上不会触发（那时 `steps` 已是 3）。

## 因此缺口落在 API 侧这一段

`completeWithProgress` 读到 `interrupted` → `readInterruptedCompletion` →
`handleInterruptedToolCall` → `markAwaitingToolPermission(pending_tool_name=
write_todos, pending_args_summary={todos:[...]})`。观察到的事实是这一段在 60s
内**没有产生任何可见结果**：DOM 里既没有回复气泡、也没有一个 `copilotkit-v2-tool-calls-group`，
`/agent-runs/:id` 最后一次读到的是 `queued`，账本一直 `preparing/running`。

## 下一步（需要真栈，不能只读代码）

起 chat-read 栈跑单条 `--grep "TW-P0-3④"`，抓 API 进程日志与 `agent_runs` 行，
判 run 停在哪一步（是否进过 `handleInterruptedToolCall`、`pending_tool_name`
落没落表）。**做之前先写可证伪预测**，别在结果出来后现编解释。

Run the chat-read stack with `--grep "TW-P0-3④"` and inspect `chat-task-workbench-workflow-states.spec.ts:143`, API logs, and the `agent_runs` row. Trace `completeWithProgress` through `readInterruptedCompletion` and `handleInterruptedToolCall` to determine whether `markAwaitingToolPermission` runs and whether `pending_tool_name` is persisted; done means the stopping point is reproducible and evidenced.

Written by the indexing model from the issue text.