`ucode revert` doesn't undo the legacy Codex in-place config edits and users get stuck routing through the workspace gateway

[dhruv0811]

For Codex CLI < 0.134.0, ucode configure takes the legacy layout in agents/codex.py (_use_legacy_layout() →
write_tool_config) and deep-merges into the user's real ~/.codex/config.toml: a top-level profile = "ucode",
[profiles.ucode], and [model_providers.ucode-databricks]. The top-level profile selector makes every bare codex
invocation route through the workspace's AI Gateway — and nothing in ucode's removal story undoes it:

1. revert() (cli.py) never restores the legacy shared config. It only restores TOOL_SPECS paths, which for codex is the
   per-profile ~/.codex/ucode.config.toml. LEGACY_CODEX_BACKUP_PATH / _legacy_backup_path() are written by
   write_tool_config / _remove_legacy_ucode_profile but referenced nowhere in any restore path. After ucode revert, profile
   = "ucode" and the ucode-databricks provider remain in ~/.codex/config.toml.
2. Users who try rm -rf ~/.ucode make it worse: that deletes the only backup and managed_configs, so the edit becomes
   unrecoverable except by hand.
3. default_model can pin a non-routable model. It picks from the foundation-models discovery (discover_codex_models); on
   a workspace whose responses-capable entries aren't gpt-* (e.g. moonshotai/kimi-k2.5), all candidates parse to (0,0,0,0)
   and one gets written as model — which the gateway then rejects:
   Invalid Unity Catalog endpoint name: 'moonshotai/kimi-k2.5'. Must be a three-part name (catalog.schema.endpoint) …
   (error_code=BAD_REQUEST)
4. plus per-launch noise from codex's models manager: 404 ENDPOINT_NOT_FOUND: Invalid path:
   /ai-gateway/codex/v1/models?client_version=0.130.0.
5. Minor: on the modern path, _remove_legacy_ucode_profile pops profile/profiles.ucode from the shared config but leaves
   an inert [model_providers.ucode-databricks] behind.

Suggested fixes: (a) make revert restore (or better, surgically strip) the legacy ~/.codex/config.toml edits — surgical
removal of the ucode-namespaced keys (profile == "ucode", profiles.ucode, model_providers.ucode-databricks) is safer
than restoring the backup, since backup_existing_file keeps only the first-ever snapshot and a whole-file restore
clobbers user edits made since; (b) filter default_model candidates to GPT-parseable/routable ids instead of max() over
whatever discovery returns; (c) have _remove_legacy_ucode_profile also drop the ucode-databricks provider block.

Reproduced against ucode@main (6e6412d) with Codex 0.130.0. For affected users today the workaround is: restore
~/.ucode/codex-config.backup.toml over ~/.codex/config.toml if it still exists, otherwise hand-delete the three ucode
entries; or upgrade codex to ≥ 0.134 and re-run ucode configure (which strips the profile selector but leaves the
provider block).