[Codex][CLI] Show model-capacity guidance on 429

[ccy-oai]

Problem

Users get generic 429s with no guidance when a model is at capacity.

Solution

Detect model-cap headers, surface a clear “try a different model” message, and keep behavior non‑intrusive (no auto‑switch).

Scope

CLI/TUI only; protocol + error mapping updated to carry model‑cap info.

Tests

  - just fmt
  - cargo test -p codex-tui
  - cargo test -p codex-core --lib shell_snapshot::tests::try_new_creates_and_deletes_snapshot_file -- --nocapture (ran in isolated env)
  - validate local build with backend

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2ff31b4f10

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve ErrorEvent context when handling model-cap errors

The model‑cap path rebuilds its own message and drops ErrorEvent.message, which can carry important prefixes (e.g., core/src/compact_remote.rs sends Error running remote compact task: …). When a model-cap error happens during those prefixed operations, the TUI will now show a generic capacity warning without context, making it look like the user’s main turn failed. Consider passing the original message into on_model_cap_error (or prepending it) so contextual prefixes aren’t lost for model-cap errors.

Useful? React with 👍 / 👎.

[ccy-oai]

intentionally not preserving the prefixed message for model‑cap. For this case we want a clear, consistent capacity warning (model + retry hint) rather than context prefixes, which can be redundant or noisy.