fix: 恢复原生会话中缺失的用户消息并支持自动复查

[130040167]

问题现象

用户发送过一段完整指令，任务也确实按该指令执行过，但之后重新打开会话，原生消息流中可能找不到这段用户原文，只能看到后续模型回复、问答卡片或补充消息。用户无法在原来的会话页面直接查看当时提出的要求，需要翻查本地日志才能确认发生了什么。

本地排查发现，部分缺失内容仍保存在 rollout 原始记录中，但 thread_history_1.sqlite 中缺少对应的 userMessage、首条用户消息关联，或整个历史轮次的投影。现有“修复历史会话”主要处理供应商归属及目录可见性，不能补齐这类原生消息索引。

修复内容

• 新增“会话管理 → 修复会话索引”，扫描当前 CODEX_HOME 的 sessions 和 archived_sessions，无需用户记住缺失文本或逐个指定会话。结果直接补入原生消息，重新打开会话即可读取。
• 普通文本必须由用户事件/原生完成事件与同轮响应记录相互印证；目标必须与同任务目标事件、对应首轮内部上下文原文一致。过滤环境信息、内部自动续执行等内容。
• 支持首条关联修复、证据明确的同轮后续补充、目标补到问答卡片前，以及开始/结束边界和归属均明确时补建缺失的历史轮次。旧 inProgress 只有在日志和数据库共同证明后继轮次已开始时才允许补消息，不改写旧状态。
• 复用已保存的“启动前自动修复历史会话”开关：启动前检查；启动器运行期间，每次检查完成后间隔 60 秒复查；关闭开关停止后续检查。退出时不再安排新检查，已开始的事务正常完成。
• 报告展示已存在、恢复、短暂等待、需核查、最后检查时间、原因、任务/轮次 ID、首次发现和复查次数。页面每 15 秒只读刷新报告，不会自行启动修复。等待持续 30 分钟，或原文及日志均超过 24 小时未更新时，明确转入核查；后续仍会重新核验。
• 按文件大小和修改时间缓存扫描结果，每次仍核对原生索引；实际待修复时先备份数据库，再获取事务写锁重新核验。

避免误恢复的关键保护

1. 首条含附件或身份不明确时，不能把后续纯文字提升为首条，也不能借用不匹配的悬空消息 ID。同批次先恢复首条后，才重新核验可恢复的后续消息。
2. 证据逐条使用，同一完成事件不能证明两次发送；同一响应区间出现多个完成事件，或独立用户事件与同文响应数量不符时，明确核查。
3. 目标按身份、创建时间及正文区分，保留同文新目标，过滤同目标续执行；跨分片优先保留已存在的旧恢复投影，避免升级后重复插入。
4. 位置冲突按原生数据库的 (thread_id, rollout_ordinal) 约束核验，冲突项不阻断其他安全项；分片归属不能仅凭文件名或正文推测。
5. 截断的 JSON 尾行不会缓存为“扫描成功”，未写完或持续损坏会进入等待/核查。未知格式、混合附件及证据不足的内容不猜测恢复。