feat: support independent SQLite home across CLI and desktop apps

[Hccake]

背景

当 Codex Desktop 使用 WSL agent 时，Codex Home 与 SQLite Home 可能位于不同的文件系统中。例如：

• 配置和 sessions 使用 Windows Codex Home
• SQLite 状态数据库存放在 WSL 的独立目录

现有实现默认从 Codex Home 下查找 state_5.sqlite，没有把 SQLite Home
作为独立存储位置处理。这会同时影响两种使用方式：

• Windows GUI 无法正确定位和处理 WSL 中的 SQLite 数据库
• 在 WSL 中运行 CLI 时，如果 Codex Home 指向共享的 Windows 目录，也无法正确定位 Linux 中的 SQLite 数据库

在这些场景下，status、sync、switch、backup 和 restore
可能找不到实际数据库，或者错误处理 Codex Home 中遗留的 stale database。

本 PR 将 SQLite Home 从 Codex Home 中独立出来，让 CLI、Windows GUI
和 macOS GUI 使用统一的路径解析与安全策略。

Related: #50

改动内容

统一 SQLite Home 解析

CLI 和桌面端现在采用相同的优先级：

1. CLI --sqlite-home / GUI override
2. config.toml 根级 sqlite_home
3. CODEX_SQLITE_HOME
4. 默认 <Codex Home>/sqlite

只有默认布局允许回退到旧路径 <Codex Home>/state_5.sqlite。

显式指定的 SQLite Home 如果缺少 state_5.sqlite：

• status / GUI“刷新”只显示诊断信息
• sync、switch 和 restore 直接失败
• 不会回退并修改 Codex Home 中可能过期的数据库

CLI

• 为 status、sync、switch、watch、backup 和 restore 增加独立 SQLite Home 支持
• Windows launcher 支持传递 SQLite Home 和 UNC 路径
• watch 在配置变化后重新解析 SQLite Home，并动态重绑 DB、WAL 和 SHM watcher
• 状态输出显示实际 SQLite Home、来源和数据库路径

备份与恢复

• backup metadata 升级为 v2
• 记录 sqliteHome 和 sqliteDbFiles
• 默认布局继续保留兼容的 dbFiles
• 仍支持恢复 metadata v1 备份
• 恢复前先验证目标数据库路径和备份文件，再修改 config.toml
• SQLite Home 发生迁移时：
  • CLI 要求显式 --sqlite-home 和 --allow-sqlite-home-relocation
  • GUI 显示备份来源和恢复目标，并要求二次确认

Windows 与 macOS GUI

• 增加 SQLite Home 输入和目录选择
• override 按 Codex Home 单独保存在 GUI settings 中
• 不会把 GUI override 写入 config.toml
• 状态区域显示实际 SQLite Home、来源和数据库路径
• Windows GUI 支持通过 \\wsl.localhost\<distro>\... 选择位于 WSL 文件系统中的 SQLite Home。
• Windows GUI 支持位于 Windows 文件系统中的独立 SQLite Home。WSL UNC SQLite Home 会被识别为仅诊断路径；GUI 显示专用安全诊断并禁用同步和恢复。Windows Codex Home 与 WSL SQLite Home 分离的场景，应在 WSL 内使用 Linux 路径运行 CLI。

CI 与文档

• 增加 Linux Node 测试
• 增加 macOS Core 测试和 Release build
• 补充 CLI、Windows GUI 和 macOS GUI 使用说明
• 文档增加 Windows Codex App + WSL SQLite Home 示例

验证

• Node CLI tests: 91/91
• Windows Core tests: 78/78
• Windows WinForms tests: 15/15
• Windows win-x64 self-contained single-file publish
• macOS Core tests and Release build
• 使用真实的 Windows Codex Home + WSL SQLite Home 执行只读 status
• 确认实际数据库解析为 WSL SQLite Home
• 确认显式 SQLite Home 不会访问 stale Codex Home database
• Windows GUI 手工交互验证
• macOS GUI 手工交互验证

真实环境验证命令：

codex-provider status \
  --codex-home /mnt/c/Users/<user>/.codex \
  --sqlite-home /home/<user>/.codex/sqlite

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 153b067e6c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Dailin521]

感谢提交。我们已经针对当前提交 7769705 在真实的 Windows 11、WSL 2.7.11 和 Ubuntu 24.04 环境中完成了 Windows GUI 与 Core 实测。

本地独立 SQLite Home 场景验证通过：状态读取、显式路径隔离、禁止回退到 stale database、同步、v2 备份及恢复均正常。因此，SQLite Home 与 Codex Home 分离的主体实现是有效的。

但 PR 当前明确宣称支持 Windows GUI 通过 \\wsl.localhost\<distro>\... 直接处理 WSL 文件系统中的 SQLite，这一核心场景实测未通过：

• GUI 能正确接受并解析 WSL UNC 路径，也没有回退到 Windows Codex Home 中的 stale database；
• 读取状态会等待约 60–65 秒，随后报告 state_5.sqlite is currently in use；
• 测试期间没有 Windows 或 WSL 进程占用该数据库，WSL 内部可以正常读取；
• 关闭 GUI 后，直接调用当前 PR 的 Core 代码仍能稳定复现相同结果。

这些证据表明该错误并非实际的数据库占用，而是 Windows 进程通过 WSL UNC/9P 访问 SQLite 时的文件锁兼容问题。SQLite 依赖可靠的文件锁语义，直接对该路径执行写入、备份或恢复不能视为安全支持。微软也建议让工具和文件位于同一操作系统文件系统，SQLite 官方则明确提醒网络文件系统的锁实现可能不可靠：

• https://learn.microsoft.com/en-us/windows/wsl/setup/environment
• https://sqlite.org/faq.html
• https://www.sqlite.org/howtocorrupt.html

因此，请在合并前至少完成以下修改：

1. 检测 \\wsl.localhost\... / \\wsl$\... SQLite Home，并禁止 Windows 进程直接执行 sync、switch、backup 和 restore 等写入操作；
2. 对此场景提供准确的诊断信息，避免误导用户去关闭 Codex 后重复尝试；
3. 相应修正 PR 描述、Windows GUI 文档和支持范围；
4. 增加真实 Windows + WSL ext4 SQLite 集成测试，覆盖读取超时以及写入、备份、恢复的安全边界，而不仅是 UNC 路径解析。

如要保留“Windows GUI 直接管理 WSL SQLite Home”的支持声明，建议改为检测发行版与 Linux 路径后，通过 wsl.exe -d <distro> 在 WSL 内部执行 SQLite 操作，并为同步、备份及恢复增加端到端验证。该完整实现也可以拆分为后续 PR；但当前 PR 应先建立安全阻断并缩小支持声明，再继续合并审查。

[Hccake]

感谢实测和说明。确认这个问题不是数据库被占用，而是 Windows 通过 WSL UNC 路径访问 SQLite 时，文件锁语义不可靠。

我已经按建议调整：

• Windows 检测到 \\wsl.localhost\... 或 \\wsl$\... SQLite Home 时，只显示安全诊断；
• sync、switch、backup、restore 和 watch 会在产生副作用前停止；
• GUI 在这种情况下会禁用同步和恢复，并提示用户改在 WSL 内运行 CLI；
• README 和 GUI 文档已经同步调整支持范围。

另外增加了真实 Windows + WSL ext4 SQLite 测试。测试会从 WSL 创建数据库，再调用 Windows Core，确认状态查询可以快速返回，相关写操作会提前停止，并且数据库、配置、rollout 和备份目录都保持不变。

本地测试结果：

• Node：100/100
• Windows Core：88 passed，1 skipped
• Windows + WSL 集成测试：1/1 passed
• Windows GUI：17/17
• macOS Release build：通过

[Dailin521]

已对提交 a770f339 完成真实 Windows 11 + WSL 2.7.11 + Ubuntu 环境验证。Windows GUI 使用真实 \\wsl.localhost\\Ubuntu\\... SQLite Home 时约 256ms 返回专用安全诊断，同步与恢复按钮正确禁用；有效 SQLite 数据库哈希未变化，配置、rollout 与备份目录均无副作用。本地独立 SQLite Home 的同步、备份、恢复以及 Codex Home A→B override 隔离也已验证通过。macOS Core/Release CI 已通过；由于暂无 Mac 设备，真实 macOS GUI 手测按约定保留为未完成项，不作为本次合并阻塞。