Sync all existing Codex state databases

[mayii2001]

Summary

• update provider metadata in every existing Codex state database instead of only the heuristically selected active database
• check writability for both ~/.codex/sqlite/state_5.sqlite and ~/.codex/state_5.sqlite before changing rollout metadata
• back up and restore both database locations when both exist
• keep the existing active-database selection for status and diagnostics

Environment

• Windows 11 Pro, version 10.0.26200 (build 26200)
• Codex Desktop 26.707.8479.0 (OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0)

Why

v0.2.9 / #48 improved active database detection, but sync still writes only the single database returned by that heuristic. After updating the database by v0.2.9 tool, the desktop history records briefly appeared and then disappeared.

Codex supports an independent SQLite home through sqlite_home / CODEX_SQLITE_HOME; otherwise it defaults to CODEX_HOME. Consequently, different Codex versions, surfaces, or launch configurations can select different paths:

• CODEX_HOME=~/.codex → ~/.codex/state_5.sqlite
• sqlite_home=~/.codex/sqlite → ~/.codex/sqlite/state_5.sqlite

A sync tool cannot reliably predict which existing database a later Desktop or app-server launch will select. Updating only the database that currently looks most active can therefore leave stale provider metadata in the other known location.

Observed locally before manual repair:

• ~/.codex/sqlite/state_5.sqlite: 262 threads using custom
• ~/.codex/state_5.sqlite: 316 threads using OpenAI, 1 using custom

The current Desktop app-server was actively writing the legacy-root database, while the sqlite-dir database appeared to be left by another version or configuration. After both databases were synchronized to custom, Desktop history remained visible instead of appearing briefly and disappearing again.

The Codex CLI/app-server and SQLite state implementation are public, but the complete Codex Desktop UI implementation is not available in the public openai/codex repository. Therefore the exact UI-side mechanism behind the brief appearance and subsequent disappearance cannot currently be established from source. Synchronizing only the heuristically selected database did not resolve the issue in this environment, while synchronizing both existing databases did.

This is related to the behavior reported in #28 and complements the active-database detection added by #48.

Safety

• all existing databases are opened and BEGIN IMMEDIATE is acquired before rollout changes are applied
• if either database is locked or malformed, sync fails before rewriting rollout files
• row counts aggregate updates across both databases
• backups contain both database paths and restore restores both

Tests

• npm test — 41 passed
• dotnet test desktop/CodexProviderSync.Core.Tests/CodexProviderSync.Core.Tests.csproj -c Release --no-restore — 43 passed

[Dailin521]

感谢提交，这个方向可以解决两个 state_5.sqlite 并存时的元数据不一致问题，备份和恢复范围也补全了。不过目前还有两个问题需要处理：

1. 两个数据库使用独立连接并依次执行 COMMIT。如果第一个提交成功、第二个提交失败，第一个已经无法回滚；外层同步错误处理也不会从备份恢复数据库，最终仍可能留下两个数据库状态不一致。建议增加跨库原子方案，或在任一提交失败时恢复全部数据库备份。
2. existingStateDbs 只按路径收集数据库，没有按真实路径或文件标识去重。如果两个位置是符号链接或硬链接，第一条连接取得写锁后，第二条连接会被自己锁住。本地硬链接场景可以稳定复现 database is locked。

建议补充对应的失败提交和同文件链接测试。修改后我再看一下。