fix(opencode): use exponential backoff when retry-after-ms is zero

[eriera1]

Issue for this PR

Closes #37076

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

When Azure OpenAI returns a 429 with retry-after-ms: 0 (which it always does for sliding-window TPM exhaustion), the session-level retry loop produce a non-capped retry storm.

This fix:

• When retry-after-ms is 0, falls back to exponential backoff (2s, 4s, 8s, 16s, 32s) instead of using the header value directly
• Caps retries at RETRY_MAX_ATTEMPTS = 5 to prevent infinite retry storms
• Non-zero retry-after-ms values are still trusted (all other providers)

How did you verify your code works?

• All 33 existing retry tests pass unchanged
• Tested against a personal Azure DeepSeek-V4-Flash deployment in Azure: confirmed retry-after-ms: 0 in every 429 response via structured logging, and that the exponential backoff produces growing delays instead of constant 1s waits.
• Typecheck passes in packages/opencode

Screenshots / recordings

If this is a UI change, please include a screenshot or recording.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found a related PR that may be worth reviewing for overlap:

Related PR:

• fix(opencode): cap retry backoff when response headers lack retry-after #33733: fix(opencode): cap retry backoff when response headers lack retry-after
  • fix(opencode): cap retry backoff when response headers lack retry-after #33733
  • This addresses a similar concern about retry backoff handling, though it focuses on missing headers rather than zero values. Worth checking if there's any overlap in the retry logic refactoring or if this PR supersedes the earlier fix.

The current PR #38697 appears to be the primary implementation for this specific issue (handling retry-after-ms: 0).