feat(continuation): 增加只读长程任务受限续跑

[zsnjuts]

背景

长程任务在模型达到输出上限或未给出业务终态时可能提前停止，需要用户手动发送“继续”。本 PR 在已合入的失败可见性修复之上，增加一个默认关闭、显式启用且只允许只读任务使用的受限续跑机制。

改动

• 增加 task-scoped lease、TTL、最大续跑次数、退避、显式取消与新用户输入失效。
• 仅在普通轮无业务 final 的 completed，或精确 model output limit exceeded: max_output_tokens 错误时续跑；不重试任意错误。
• 每个续跑轮强制只读文件系统、禁网、空环境与 runtime roots；MCP/Skill 能力无法证明安全时 fail closed，并对精确 synthetic turn 拒绝 native subagent。
• 使用严格 JSON 业务终态，由 daemon 持久化并幂等投递 completed、await_user 与停止告警；重启后可恢复未完成 lease。
• 增加 botmux continuation start --readonly、await-user、cancel 控制面及 BOTMUX_READONLY_CONTINUATION_ENABLED=true kill switch。

影响面

• 默认关闭，未设置 kill switch 的所有会话维持原行为。
• 仅支持显式 opt-in、TraeX RPC 已就绪的普通 Lark 用户轮；写任务、schedule、VC、adopt、HTTP、无 lease 普通问答与刻意静默均不自动续跑。
• 不改写 thread capability 选择；发现外部 MCP、带工具依赖的 enabled Skill 或畸形能力证明时拒绝续跑。

验证

• 最新 upstream/master 基线：60b460c1d8301717589c5cf927da410f041e2fb7。
• 13 个 continuation、RPC、session lifecycle、dashboard、native-subagent、bridge、CLI、worker 与普通恢复相关测试文件：861 passed、1 skipped、0 failed。
• tsc --noEmit、git diff --check 通过。
• 逐条执行 bun run build 的实际组成步骤全部通过：domain audit、图标生成、dist clean、TypeScript、scripts/test-mocks typecheck、runtime build id、scope copy、dashboard bundle、dist 与 embedded-assets audit。本机无 Bun，因此未执行 Bun 命令调度层本身。
• 无前情只读审查：P0=0、P1=0、P2=0。

本 PR 未部署、未重启共享 BotMux。

[deepcoldy]

自动评审初步意见（首审），最终以维护者审阅为准。

整体设计扎实：lease 状态机、TTL/次数上限、精确终态匹配（仅普通轮无业务 final 的 completed，或精确的 model output limit exceeded: max_output_tokens）、turn 级只读沙箱、MCP/Skill 能力证明 fail-closed、worker/daemon 双侧 generation 绑定、严格 JSON 终态、稳定 UUID 幂等投递与重启恢复，这些防线方向都正确，默认关闭也保证了零配置零行为变化。

但真机验证发现 1 个需要先处理的问题：

F1（建议合入前修）：只读续跑轮挡不住 provider 内置的 WebSearch，"禁网 / 无外部副作用"的承诺与实际不符。

在真实 traex 0.204.1 上直连 app-server 验证（不是 fake fixture）：对续跑轮按本 PR 的参数下发
sandboxPolicy: { type: 'readOnly', networkAccess: false } + environments: [] + runtimeWorkspaceRoots: []，
然后指示模型调用内置 WebSearch —— 该工具仍然真实执行并返回实时网络结果（turn/completed status=completed，item 类型 webSearch），且其动作枚举还包含 open_page（可打开任意 URL）/ find_in_page。

现有的三道能力闸全部照不到它：

• 它不出现在 mcpServerStatus/list（不是 MCP server）；
• 它不在任何 skill 的 dependencies.tools 里；
• 它不经过 native-subagent runtime hook。

另外试过每轮 tools 参数的 5 种写法（{web_search:false}、{webSearch:false}、'deny'、{enabled:false}、组合 viewImage）均被静默忽略，搜索照常执行。

好在协议提供了可发现的接口：modelProvider/capabilities/read 返回 { "namespaceTools": true, "imageGeneration": true, "webSearch": true }。建议在 checkReadonlyContinuationCapabilities 中把 webSearch / imageGeneration（以及未来新增的内置联网/副作用能力）为 true 也判为 ineligible（与当前"存在任何 MCP server 记录即拒绝"同样的 fail-closed 姿态），或找到在真机上确实生效的按轮禁用字段。否则一个自动循环（最多 12 轮、可能跨 4 小时）在"只读、禁网"的名义下仍可对外发起搜索/浏览，安全声明过强。

其余为非阻断建议：

1. worker 侧 flushPending 的三道闸（readonly_continuation_rpc_unavailable / rpc_proof_mismatch / dispatch 前再探能力）目前没有直接测试（session-lifecycle 的测试用 forkMock，不加载真实 worker.ts）；parseReadonlyContinuationOutput 的严格键校验也建议补单测。
2. 合成轮在 worker 进程（非 RPC 引擎）中途崩溃时，lease 会一直停在 active 直到 TTL（默认 1 小时）才发停止告警；可考虑在 worker 换代时立刻转 failed/backoff。
3. 合成轮返回 ambiguous 终态时可能与普通 ambiguous 失败卡形成重复通知，建议核对一次。
4. 实验性命令目前只在 CLI help 里出现，建议在文档里补一句 kill switch 与能力前置条件（真机环境里只要配置过任何 MCP 或带工具依赖的 skill，资格探活就恒为 false，start 返回的 409 也没有透出 capability.reason，排障会比较困难）。

验证侧我本地复跑：tsc 0 错误、build 通过、13 个相关测试文件全部通过，并对沙箱降级/MCP 拒绝/资格限定/新输入取消四处做了变异验证均能转红；只读沙箱的参数形状、能力盘点响应形状、精确错误消息前缀均在真实 traex 0.204.1 上核对一致（fake fixture 与真机形状相符，唯独内置工具这一面是 fake 测不出来的）。