fix: sync providers in local_thread_catalog

[XIUDENBENNY]

Summary

• discover Codex SQLite databases that only contain the newer local_thread_catalog table
• include provider IDs from both threads and local_thread_catalog in provider sync target discovery
• count and update model_provider in both tables within the same SQLite transaction
• keep the existing provider-sync result shape and database backup flow unchanged

Problem

Recent Codex desktop builds maintain a second history catalog at sqlite/codex-dev.db/local_thread_catalog. Provider sync currently rewrites rollout session_meta.model_provider and threads.model_provider, but it does not update this newer catalog.

After switching from an official subscription to a custom provider, the rollout files and legacy index can be synchronized while the desktop catalog still contains the old provider IDs. Codex then filters or rebuilds the sidebar from inconsistent metadata, so only conversations originally created with the active provider remain visible.

Implementation

• treat local_thread_catalog as a session database marker in codex_sqlite_dir_session_dbs
• read provider IDs from both supported tables
• aggregate update counts from both tables
• update both tables in one transaction when they coexist in a database
• include catalog-only databases in the existing backup path

Tests

• added coverage for a codex-dev.db containing only local_thread_catalog
• verifies provider discovery, row updates, update counts, and backup creation
• added rollback coverage proving a catalog update failure also rolls back the preceding threads update
• cargo fmt --all -- --check
• cargo test -p codex-plus-data --test provider_sync (19 passed)
• frontend npm install --package-lock=false and npm run vite:build
• workspace tests passed until the local Windows installer test executable required elevation (os error 740); GitHub Actions will run the complete elevated Windows job

Related to #726 and #240.

[XIUDENBENNY]

不同的中转api或者订阅在codex++中切换后，聊天内容任完全保留