fix(codex): scope CLI configuration to launch

[wolfyy970]

Closes #2517.

Why

omlx launch codex currently writes its model and provider into ~/.codex/config.toml. Those values survive the CLI process and can affect the next normal Codex launch. The integration also has the selected model's effective context window but does not give it to Codex.

This is a narrow CLI fix while draft #2470 develops the full desktop and hybrid-routing integration. It does not change codex_app.py or try to duplicate the interceptor.

What changed

• pass the oMLX provider through Codex's process-scoped -c overrides
• pass the selected model's effective model_context_window
• keep the selected model on Codex's existing -m argument
• preserve explicit oMLX reasoning metadata for the launched process
• leave model_auto_compact_token_limit unset so Codex derives its current 90% threshold
• stop the CLI launch path from calling the persistent config writer

The user's normal Codex config remains available underneath these overrides, including [agents], MCP servers, sandbox settings, and other preferences.

Verification

• uv run pytest tests/test_integrations.py -q (107 passed)
• uv run pytest tests/ -m "not slow and not integration" -q (7,796 passed, 64 skipped, 71 deselected)
• uv run ruff check omlx/integrations/codex.py tests/test_integrations.py
• parsed the generated provider and context overrides with Codex CLI 0.146.0-alpha.9.2
• confirmed the SHA-1 of ~/.codex/config.toml was unchanged before and after the CLI validation

Relationship to #2470

#2470 is the stronger long-term design for Codex Desktop. It preserves native local and cloud model slots, adapts the model catalogue with the real local context window, and handles the desktop process lifecycle through a scoped proxy.

This PR only makes the existing custom-provider CLI launch safer and context-aware. Codex's app command currently accepts -c syntactically but does not forward those overrides to the macOS app process, so codex_app is intentionally out of scope.