Transient provider overloads can outlive the hardcoded retry schedule
(5 retries, 2s/4s/8s/16s/30s), causing sessions to give up mid-task.

Add an optional top-level `retry` config object with optional
`initial_delay_ms`, `backoff_factor`, `max_retries`, and
`max_delay_ms` fields that override the corresponding constants in
SessionRetry when present. When the config has no `retry` object the
schedule is byte-identical to before. Retry-After / Retry-After-Ms
response headers still take precedence over the exponential schedule,
and non-retryable errors are never retried.

…1.18.18-patched.4bf6d7bdc

- max_retries now accepts any integer; negative values mean unlimited retries\n  (keeps old docs default of 5, no behavior change when unset).\n- Version string documents the local patch lineage: 1.18.18-patched.4bf6d7bdc.

A model can now declare a `fallback` (provider/model) plus optional
`fallback_cooldown_ms`. On a 429/rate-limit error the session swaps to
the fallback for the rest of the cooldown window instead of burning
retry attempts, then returns to the original model. Retry-After /
Retry-After-Ms headers take precedence over the configured cooldown,
and fallback chains are walked (cycle-safe) when the target is also
cooling. 429 is additionally treated as retryable by the schedule.

# Conflicts:
#	bun.lock
#	packages/opencode/package.json