[xiaozixiaobei]

Fixes #2567

部分机器上用量状态栏长期停在 -- tok/s / 缓存命中 -- / --。根因不在渲染，而在选库：codex_session_db_path_from_home 取「第一个带 threads 表」的候选库当主库，只看表存在性，不看表里有没有行。机器上同时存在 ~/.codex/sqlite/state_5.sqlite（结构完整、0 行的历史库）和真正存会话的 ~/.codex/state_5.sqlite 时，前者排在候选序列前面，codex_thread_rollout 在主库查不到会话就直接返回 Thread rollout path is empty，不再看其它候选库，于是 /thread-usage-live 与 /thread-usage-history 稳定失败。

改动

crates/codex-plus-data/src/storage.rs 的 codex_thread_rollout 改为按 allowed_db_paths 顺序回退（主库在首位），命中有效 rollout 即返回，全部落空时才返回失败对象。读取改用 SQLITE_OPEN_READ_ONLY，打开前用 is_file() 过滤不存在的候选。只影响这两条用量路由，删除会话、导出 Markdown、主题等路径不变。

验证

• 本机（macOS 27.0.1，Apple Silicon，Codex++ 1.9.0）安装该构建后，~/.codex-session-delete/codex-plus.log 中 /thread-usage-live 从连续 272 次 status=failed 变为全部 status=ok；同进程的 /backend/status、/settings/get 前后一直正常，可对照。
• 状态栏轮询间隔由 5 秒（占位）收敛到约 1.22 秒，即渲染侧「有快照、本轮在跑」那一档，界面恢复数字。
• 正式回归测试保留在 crates/codex-plus-data/tests/storage_adapter.rs，同时验证 history/live：首库结构完整但没有目标行（空库或只有其他会话）、目标行 rollout 为 NULL/空白/不存在的文件，均继续回退到含目标会话及有效 rollout 的候选库。
• 缺失主库/候选库不会被创建；内容为非 SQLite 字节的损坏候选会被跳过，后续有效库仍能返回用量事件。
• 同一组夹具对照：使用修复前的 codex_thread_rollout 时，3 项新增回归均失败；恢复本 PR 实现后，cargo test -p codex-plus-data --test storage_adapter 全部 32 项通过。成功断言包含目标 rollout 路径，以及 1200 输入 token / 1320 总 token，避免仅检查状态。
• 前端 npm run vite:build、macOS cargo build --release -p codex-plus-manager 及应用签名检查通过。本轮界面启动验收未完成：Launch Services 返回 kLSNoExecutableErr；直接执行在 macOS _RegisterApplication 阶段中止，尚未验证应用窗口。

已知限制

• 根因仍在 codex_session_db_path_from_home：它挑主库时只看表存在性。该函数同时被 zed_remote 注册表、会话删除等路径共用，改动面较大，本 PR 未一并处理；若要根治，建议单独评估选库规则（例如按目标会话评估候选库）。
• 若某环境所有候选库都没有该会话的 threads 行（已知的纯 API 模式情形），本改动不覆盖。whale_rollout_path 有按 -<thread_id>.jsonl 扫描 sessions/ 目录的兜底，用量路由暂无同类兜底。

[BigPizzaV3]

复核当前 head ed636f98：按 allowed_db_paths 查找有效 rollout、只读打开数据库及跳过不存在候选的方向可接受，本轮未发现确定的代码阻塞问题。

本地重新运行既有用量相关测试 3 项通过；额外隔离验证 3 项也通过，覆盖空主库回退、损坏 SQLite 候选后继续回退、NULL/缺失 rollout 继续回退，以及不存在候选不会被创建。history/live 两条读取路径都已验证。

请将核心回退场景正式保留在 crates/codex-plus-data/tests/storage_adapter.rs，至少覆盖“结构完整但没有目标行的首库 + 含目标会话的候选库”，并包含 NULL 或失效 rollout 路径。PR 说明中的临时验证已证明修复，但仓库里的长期回归也应守住这次行为变化。

发布前已再次核对当前提交的 CI run 38883283061：Windows artifacts：运行中；macOS DMG (universal)：通过。 核心回退回归请正式保留，完成后再进入合并候选。

[BigPizzaV3]

复核当前 head cf4b274f，审核通过。此次相对上轮已审版本只新增正式回归，运行时代码未变；此前要求的空首库/无目标行、NULL/空路径/失效 rollout，以及不存在或损坏候选库等场景均已保留在 storage_adapter.rs。

已从当前 head 的隔离源码执行 cargo test --offline --locked -p codex-plus-data --test storage_adapter thread_usage，实际运行 6 项，全部通过，history/live 两条路径均覆盖，且验证了只读查询不会创建不存在的库。当前与 main 5e2762d9 无合并冲突。

新 head 的 workflow run 38930608623 已获维护者批准；代码审核通过，最终合入仍以该 head 的 Windows artifacts 和 macOS universal DMG 完整结果为准。

[xiaozixiaobei]

当前 head cf4b274 的 Windows artifacts 和 macOS universal DMG CI 均已通过，正式回归也已按要求补齐并获审核批准。看到 #2567 已由主线提交 5126bfd 修复并随 v1.10.0 发布，而本 PR 目前与 main 存在冲突。请确认本 PR 是否按“已由主线替代”关闭，还是希望我基于最新 main，仅补充主线尚未覆盖的回归测试？