修复多数据库会话撤销恢复

[38yuanzhao]

问题

新版 Codex 可能同时保留根目录和 sqlite/ 目录下的会话数据库。Codex++ 删除重复会话时会遍历所有候选库，但此前只返回最后一个备份 token；共享 rollout 往往已被第一个备份保存并删除。撤销又固定写入启动时选中的数据库，忽略备份中的 source_db，遇到新旧 schema 差异时会报 no column named recency_at。

变更

• 多库删除时把所有叶子备份 token 编码进一个不透明 undo token，单库 token 保持兼容。
• 撤销时按每份备份的 source_db 恢复到原数据库；launcher 显式传入实际候选数据库 allowlist。
• 在任何数据库正式提交前，用 SQLite savepoint 对全部恢复写入做预演并回滚，同时预检 rollout 路径、冲突和 base64 内容。
• 当前会话删除后延迟重载，保留 10 秒撤销窗口；撤销成功后直接刷新页面。

验证

• cargo test -j 12 -p codex-plus-data
  • 21 个 storage 测试通过
  • 覆盖根 state_5.sqlite 与 sqlite/state_5.sqlite、共享 rollout、recency_at schema drift、跨库预检失败和外部数据库路径拒绝
• cargo check -j 16 -p codex-plus-launcher
• cargo fmt --all -- --check
• node --check assets/inject/renderer-inject.js
• git diff --check

边界

这是对 #1419 的互补修复：本 PR 处理多数据库 token/source 路由和撤销后的 UI 刷新，不重复其单库文件回滚工作。项目分组的 thread-project-assignments 和 local_thread_catalog 修复仍属于 #1559 / #1438 的范围。

跨多个 SQLite 最终提交与 rollout 文件写入仍不是分布式原子事务；本 PR 通过全量预演消除正常 schema/约束失败导致的半恢复，但不引入额外事务框架。

关联：#1282、#1543、#1546、#1558。