Add built‑in exponential backoff & retry on OpenAI API rate‐limit errors

Summary

Codex wrote this issue for me:
Currently any 429 "rate limit" response from the OpenAI API bubbles all the way out and causes the Codex‑CLI process to crash. We should instead catch rate‑limit errors, wait (with exponential back‑off), and retry automatically, so brief spikes don't kill the user's session.

Problem

• Hitting the OpenAI API rate limit immediately aborts the CLI.
• Users lose work/context when a single 429 becomes an unhandled exception.
• There is no way to tune retry parameters or gracefully recover.

Proposal

1. Introduce a helper, e.g. codex/utils/openai_backoff.py:

```python
import time
from openai.error import RateLimitError, OpenAIError

def openai_with_backoff(fn, args, max_retries=10, initial_delay=1.0, *kwargs):
"""
Wrap any OpenAI call (fn) so on RateLimitError it waits and retries
with exponential backoff (capped at e.g. 60s).
"""
delay = initial_delay
for attempt in range(max_retries):
try:
return fn(args, *kwargs)
except RateLimitError:
print(f"⏳ Rate limit hit, sleeping {delay:.1f}s (attempt {attempt+1}/{max_retries})")
time.sleep(delay)
delay = min(delay * 2, 60.0)
except OpenAIError:
raise
raise RuntimeError(f"OpenAI call failed after {max_retries} retries")
```

1. Monkey‑patch the two main entrypoints in startup (e.g. in codex/cli.py):

```python
import openai
from codex.utils.openai_backoff import openai_with_backoff

_orig_chat = openai.ChatCompletion.create
openai.ChatCompletion.create = lambda args, *kw: openai_with_backoff(_orig_chat, args, *kw)

_orig_comp = openai.Completion.create
openai.Completion.create = lambda args, *kw: openai_with_backoff(_orig_comp, args, *kw)
```

1. Expose max_retries/initial_delay in user config or CLI flags.
2. Add unit tests that simulate openai.error.RateLimitError and verify retry logic.

Benefits

• CLI no longer crashes on intermittent rate limits.
• Configurable retry policy for power users.
• Better out‑of‑the‑box resilience under heavy load.