fix: 修复 Codex Desktop WSL 模式会话同步

[Sisyphbaous-DT-Project]

问题背景

Codex Desktop 开启 [desktop] runCodexInWindowsSubsystemForLinux = true 后，CODEX_HOME 可以位于 Windows，而当前实际使用的会话索引位于 WSL 的 CODEX_SQLITE_HOME。现有 Provider 同步只扫描 Windows CODEX_HOME 下的 SQLite，因此会出现：

• JSONL 与 Windows 旧索引已经更新；
• WSL 实时 threads.model_provider 仍保留旧 Provider；
• 管理器显示同步成功，但 Desktop 侧边栏仍按旧标签过滤历史。

修复内容

• 仅在 Windows 且 Desktop WSL 开关开启时启用 WSL SQLite 同步，其他平台和现有非 WSL 流程保持不变。
• 通过默认发行版的 wsl.exe 动态发现 ${CODEX_SQLITE_HOME}，并回退扫描 $HOME/.codex/sqlite 与 $HOME/.codex/state_*，只接纳包含 threads 表的数据库。
• 将 WSL 数据库中的 Provider ID 加入同步目标发现，未来新增会话或供应商不依赖硬编码 ID。
• 写入前使用 BEGIN IMMEDIATE 检查可写性；使用 SQLite .backup 创建在线一致性备份；单事务更新 model_provider、has_user_event、cwd；提交后执行 PRAGMA quick_check。
• WSL 更新失败时自动从备份回滚，并让管理器/启动器返回明确失败，避免假成功。
• sqlite_rows_updated 保持 Windows + WSL 总数，同时增加独立的 wsl_sqlite_* 统计并在管理器显示。
• 启动前自动同步不再吞掉 Skipped/失败状态。

安全与兼容性

• 所有动态 SQL 文本均编码为十六进制 SQLite 文本表达式，更新脚本通过 stdin 传入，避免命令行长度与注入问题。
• 不通过 UNC 路径直接写正在使用的 WSL SQLite。
• 不增加 Cargo/npm 依赖。
• WSL 开关开启但无法发现正本、缺少 sqlite3、数据库被占用或完整性校验失败时，整次同步明确失败。

验证

• cargo.exe test --workspace
• cargo.exe test -p codex-plus-data
• cargo.exe test -p codex-plus-manager -p codex-plus-launcher
• npm run check
• npm run vite:build
• node tools/i18n-verify.mjs
• 手动启用两个默认忽略的 Windows/WSL 隔离测试：
  • WSL 发现 → 计数 → 可写检查 → 在线备份 → 三字段更新 → quick_check → 回滚
  • 公开 Provider 同步入口同时更新 JSONL、Windows SQLite 与 WSL SQLite，并验证备份清单和目标发现

上述测试均通过。