fix: retry transient errors before falling through combo chain

[East-rayyy]

Summary

• When all API keys for a provider are temporarily locked (e.g., 503 "No capacity"), wait for the short cooldown and retry the same model before falling through to the next combo model
• Adds extractRetryDelayMs() helper to read Retry-After header and retryAfter body field
• Configurable: max 10s delay, max 2 retry attempts per model

Fixes #335

Problem

A combo like antigravity/opus → github/opus would immediately fall through to GitHub when both Antigravity keys got transient 503s with 1-2 second cooldowns. Simply waiting 1-2 seconds would have let the request succeed on Antigravity, but instead it hit GitHub (which may have no active credentials), killing the client.

How it works

Inside handleComboChat, after a model fails with a fallbackable error:

1. Extract retry delay from Retry-After header or retryAfter in the JSON body
2. If delay ≤ COMBO_RETRY_MAX_DELAY_MS (10s) and attempts < COMBO_RETRY_MAX_ATTEMPTS (2): wait, then retry the same model
3. If delay is too long, retries exhausted, or no retry info: fall through to next model (existing behavior)
4. Permanent errors (401, 403, etc.) are never retried — shouldFallback check runs first

Change

1 file changed — open-sse/services/combo.js

The for loop over models now wraps each attempt in a while loop that handles retries. All existing behavior is preserved when no Retry-After is present.

Test plan

• Combo with a provider that returns 503 with short Retry-After → should retry and succeed
• Combo with a provider that returns 503 with long Retry-After (>10s) → should fall through immediately
• Combo with a provider that returns 401 → should not retry, fall through immediately
• Combo where retries are exhausted → should fall through to next model
• Combo with no Retry-After header → existing behavior preserved (immediate fallthrough)
• Normal (non-combo) requests → unaffected