真实链路上暂停不生效：run_control 的生产方在 apps/ 与 packages/ 里根本不存在（F3 的绿只覆盖替身）

## 现象

devapp 上（真实链路，非回环替身）点「暂停」后，界面停在「正在暂停 / 暂停中…」，run 并未真正停下。人类实测 2026-09-10。

## 为什么车道是绿的却没抓住

`@path:F3`「暂停真的停下来」在 `chat-path-coverage` 车道上**是绿的**（#3303 → PR #3307）。但 #3307 做的事是：让**回环替身**学会说 `user_pause` 这门方言（此前替身里 `interjection` / `user_pause` / `pauseRequested` 三个词 grep 计数为 0，`paused_at` 在该车道上根本没有写入路径）。

所以那条绿证明的是「**替身链路上**暂停有效」，**没有**证明真实 kernel 链路上有效。人类实测正好落在它证明不了的那一半。

这是本仓最贵的那个形状的又一次实证：**替身产不出缺陷的形状 ⇒ 判据无法被证伪**。#3307 的诊断方当时还专门核对了替身方言与真实上游的一致性（对 `run_control.py::_request`、`ops.py::set_joint_status`、`state.py::patch_interrupt` 取证），仍然没能覆盖这一段——说明**方言对得上 ≠ 真实链路走得通**。

另一条独立佐证（来自 #3312 的对照实验）：#3307 新增的三条路径在本仓**生产侧全部够不到**——`run_control_callback` 的生产方在 `apps/` 与 `packages/` 里一个都不存在，`record.runControl` 恒 `undefined`，`pollRunControl` 一次都不会被调用；`deep-agent-model-provider.ts` 从不请求裸 `GET /threads/:id`。**这很可能就是真栈暂停不生效的直接线索**：替身自己实现了这条链，生产代码里没有对应的一端。

## 要求

- **先取证再动手**：真实链路上点暂停之后，`POST /runs/pause` 是否返回成功、`pauseRequestedAt` 是否落库、kernel 是否收到 `user_pause` 中断、`paused_at` 是否被写入——逐段确认断在哪一环，不要从代码结构推断。
- 修好之后，**判据必须能在真实链路上被证伪**，不能再只靠替身。若真栈判据成本过高，至少要明确写出「本判据覆盖到哪一层、哪一层没覆盖」，不要让下一个人再次误以为绿等于全覆盖。
- 关联：**#3318**（人类裁决：先移除暂停入口，只保留取消）——本 issue 是那条止血措施的根因项。暂停功能修好之前，入口不应回来。

Reproduce the devapp pause flow and verify POST /runs/pause, pauseRequestedAt, the kernel user_pause interrupt, and paused_at in sequence. Then inspect run_control.py::_request, ops.py::set_joint_status, state.py::patch_interrupt, run_control_callback, record.runControl, pollRunControl, and deep-agent-model-provider.ts to locate the missing production link. Done means real-chain pause works and the test states exactly which layers it covers.

Written by the indexing model from the issue text.