fix(channel): 修复问答与审批续跑后的输出丢失

[qqqqqf-q]

修复 ask_user / 工具审批接受后，后台继续运行但渠道收不到后续回复的问题；同时处理输出突发、通知丢失和答案已接受却被显示成提交失败的情况。

实现与复用边界

提交前建立按命令隔离的输出检查点，直接复用现有 Backend.Update 和 Manager.Subscribe：先写快照，再发布通知；序号缺口和通知丢失由网页使用的同一订阅机制通过快照恢复。64 条缓冲只负责实时通知，不再承载唯一输出。每个命令有独立游标，避免同一 run 的下一张问题卡片与上一次续跑混淆。

答案接受后立即发送内部接受回执，渠道消费回执并同步原问题卡片，然后继续转发模型输出。接受后的输出错误使用既有 agent_response_interrupted 错误契约，不把它描述成答案提交失败。重复命令保持确认语义，不重新执行模型或自动重发 Telegram 消息。

复用现有运行快照检查 owner/run 终态；结束检查点无法写入时，走既有运行失败收尾，避免继续停留在等待新问题的状态。没有新增数据库迁移、消息队列、依赖或另一套运行状态机。

与 #1156 的关系

两个 PR 均面向 main，diff 不互相包含，完整 Telegram 工作流需要一起验证。#1156 处理答案接收、按钮 fence、Stop 与持久交互清理；本 PR 处理接受确认和后续输出。#1156 同步修正了 handler 输出失败时仍根据持久提交状态更新卡片的兜底路径。

成本与限制

• 每个命令最多保留 8 MiB 原始输出、32768 条事件，沿用 Backend 的生命周期/TTL；超限显式中断，不静默丢弃。
• 原始输出检查点保留渠道需要的卡片及附件事件，不能直接用网页消息投影替代。当前每次输出更新完整快照，存在累计序列化和写入成本；这是复用现有机制的明确取舍。
• 这不是持久化渠道 outbox，不承诺外部消息 exactly-once 或进程重启后的完整补发。Memory 进程状态丢失、Redis 状态丢失仍是恢复边界。
• 运行终态/归属变化负责异常收尾；输出慢或通知丢失不再直接等同于输出丢失。

代码量与重点审查

按共同祖先 67fe0e6 到 head f3a3f18 统计（base...head）：

分类	新增	删除	净变化
全部 diff	837	31	+806
测试，含测试注释与空行	468	2	+466
自动生成内容	0	0	0
生产文件，含注释、空行和格式调整	369	29	+340
其中纯空白对齐调整	14	14	0
有效生产代码，排除纯注释、空行及上述对齐	317	15	+302

有效生产代码原为净增 78，本次版本为净增 302。新增主要用于检查点与共享订阅接入、异常运行收尾、接受回执及接受后的错误处理；没有单独复制网页的缺口修复/定期对齐算法。

重点 review：快照保留上限与写入成本、同 run 多次问题的命令隔离、owner 终态收尾、接受回执与输出错误的区分。当前版本仍保持 Draft。

验证

最终 head 的 session/application/inbound 定向测试及 race 复跑通过，覆盖 133 条输出突发、通知及结束通知丢失恢复、运行终态退出、保留上限、结束检查点写入失败和接受回执错误语义。真实隔离 Redis 的通知丢失恢复用例通过。最终组合提交 7ef647e3e 的全仓库 Go 测试及 lint 均通过；定向 lint 也通过。首次 race 有命令确认超时，未改断言或超时参数的最终复跑通过；不据此推断全系统无并发问题。修改前后的 Redis 完整契约测试都出现短租约/运行归属相关失败；不能将完整 Redis 契约标为通过。最新代码尚未部署到 Telegram QA 环境，也未完成人工 QA；此前旧组合版本的人工 happy path 不代表本次 head。

⚠️ No human QA — this PR has not been verified by a human yet. Remove this line once a human confirms the happy path.