Add a config profile selector to Codex Desktop for <name>.config.toml files

A concrete Windows Desktop use case for this selector is per-task context-window profiles.

I need two profiles for the same project and account:

# normal.config.toml
model_context_window = 272000
model_auto_compact_token_limit = 220000
model_auto_compact_token_limit_scope = "total"

# long-context.config.toml
model_context_window = 1050000
model_auto_compact_token_limit = 750000
model_auto_compact_token_limit_scope = "total"

Some long-running reverse-engineering and integration tasks lose too much working context after aggressive compaction or handoff, so they genuinely benefit from the larger window. Most ordinary tasks do not need it.

Making the 1M setting global is problematic: in one measured long Desktop thread, the effective window was 828,400 and repeated small continuation cycles processed roughly 200k cached tokens per event. Reducing the global configuration to 272k produced an effective 258,400 window and reduced average local token volume, but it also made complex long-horizon continuity harder. Related usage evidence is documented in #34971.

The desired workflow is therefore:

1. Keep the base/default profile at the smaller context window.
2. Select long-context only when creating a task that needs it.
3. Snapshot and visibly retain that profile for the task.
4. Do not change other running or resumed tasks when another task selects a different profile.
5. Show the effective context window and auto-compaction threshold in task details, so users can verify what was applied.

New-task selection is sufficient; mid-turn hot switching is not required. A dedicated context preset in the composer would also solve this narrower use case, but reusing the existing named profile mechanism seems more general and avoids adding another configuration system.

This would let users trade continuity against rate/latency cost intentionally per task instead of repeatedly editing the global config.toml or fragmenting work across short threads.

Important current caveat: the 1M option can amplify the existing replay bug

Until the repeated cached-context processing reported in #34971 is fixed or ruled out, opting into a 1M profile can currently be a trap rather than a simple continuity/cost choice.

A larger retained window gives the task more history to understand, but it also gives the affected continuation/re-entry loop more cached history to process repeatedly. In the measured case, 99%+ of input was cached and individual small progress cycles still recorded roughly 200k local tokens, while the user-visible Codex allowance appeared to drain rapidly. The 1M configuration increased the impact compared with the smaller configuration.

Local token telemetry is not asserted to equal the private subscription billing ledger one-to-one. The observable combination is nevertheless concerning: a larger context setting, repeated near-full-history processing, and substantially faster user-visible allowance depletion.

Therefore, a Desktop profile selector should not present 1M as an unqualified “more context” upgrade while this behavior remains possible. It should ideally:

• warn that larger windows can materially increase repeated cached-input usage;
• show current cached, uncached, and cumulative usage for the task;
• warn or stop automatic re-entry after several consecutive high-token, low-progress cycles;
• make the selected profile and effective context window unmistakable; and
• allow users to keep ordinary tasks on the smaller profile while containing 1M exposure to explicitly selected long-context tasks.

Per-task profiles are still the desired mitigation, but they should complement—not conceal—the underlying replay/compaction bug.