Keep Codex threads alive with shared 429 backoff

[alicon]

What changed and why

Concurrent ug codex processes share a Databricks model rate limit while Codex itself has a finite retry budget. This keeps the selected model and reasoning effort intact while making those sessions wait and resume instead of terminating on a 429.

The change:

• keeps proactive per-workspace/model input-token pacing for models with published limits;
• absorbs every upstream 429 inside the loopback proxy;
• honors Retry-After, otherwise uses capped exponential backoff with jitter;
• coordinates cooldowns across processes, with a workspace-wide fallback when the model is unreadable or unknown;
• restores the pre-ucode managed_config.toml baseline because that higher-precedence direct provider silently bypasses the loopback proxy;
• preserves unrelated machine policy and blocks an external provider value only when it would still bypass the proxy.

No prompt, response body, header value, or credential is persisted.

Validation

• 2309 passed, 9 skipped, 1 deselected with a short macOS temp path; the deselected Codex wire-level test passed separately after the live managed-config migration.
• ruff check ., ruff format --check src/ tests/, and ty check src/ passed.
• Installed-package smoke tests covered 429 -> shared wait -> internal retry -> 200 over loopback and fake-gateway sockets.
• A real installed gpt-5.6-sol / xhigh turn completed through the loopback provider, and ~/.ucode/codex-rate-limit-state.json advanced in the Sol bucket.

Technical record

• BADDLO-373
• Head: 33119e58eae92adcdc1aa0483daa1eff27c8991f
• Installed and live-observed as ucode 0.1.0+90.g33119e5 with /etc/codex/managed_config.toml absent.