Make stream reconnect delay/backoff configurable in config.toml

Hard-coded exponential backoff for retryable stream reconnects makes some provider setups unusable.

Today Codex exposes stream_max_retries, but not the reconnect delay strategy. The outer reconnect loop uses a fixed exponential backoff starting around 200ms and doubling on each retry, so by the time a session reaches the low teens it is already waiting many minutes between attempts.

That is a poor fit for providers / gateways that frequently fail with retryable transient errors but often recover after a few quick retries. One concrete case is OpenAI-compatible upstreams that may briefly return 403 Forbidden with an "insufficient balance / quota" message and then succeed again shortly afterward once the upstream gateway refreshes state or routes to a healthy backend.

In that setup, users can already raise stream_max_retries, but they cannot express the retry cadence they actually need. By retry 10+ the built-in exponential backoff dominates and the CLI can end up waiting far longer than the upstream outage itself.

Proposed behavior:

1. Keep the current default behavior for existing users.
2. Add provider-scoped TOML settings so users can choose the reconnect delay behavior explicitly.
3. Support at least:

• a configurable base delay in milliseconds
• a configurable backoff mode (exponential or fixed)

Example desired config:

[model_providers.custom]
stream_max_retries = 100
stream_retry_delay_ms = 500
stream_retry_backoff = "fixed"

That would allow the common "retry every 500ms" workflow without requiring a local patch.

I have a PR ready that implements exactly this shape while preserving the current default behavior.