fix(opencode): cap retry attempts at 5 to prevent infinite loops

[niStee]

Issue for this PR

Closes #29143

Type of change

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

What does this PR do?

Prevents infinite retry loops when a provider consistently fails by capping retry attempts at 5. This ensures the fallback system can proceed to the next configured model instead of spinning indefinitely on a broken provider.

How did you verify your code works?

Tested locally by simulating a consistent provider failure and verifying that the retry loop breaks after 5 attempts, correctly returning an exhaustion status to the caller.

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]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

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

Based on my search, I found related PRs that address retry logic and capping attempts:

Potential Related PRs:

1. PR fix(session): retry network errors, cap at 3, add retry_exhausted status #28792 - fix(session): retry network errors, cap at 3, add retry_exhausted status

   • fix(session): retry network errors, cap at 3, add retry_exhausted status #28792
   • Related because it also caps retry attempts (at 3 instead of 5) and adds exhaustion status

2. PR fix(session): cap retry schedule at RETRY_MAX_ATTEMPTS = 3 #26369 - fix(session): cap retry schedule at RETRY_MAX_ATTEMPTS = 3

   • fix(session): cap retry schedule at RETRY_MAX_ATTEMPTS = 3 #26369
   • Related because it also implements retry attempt capping with a constant

Why they're related: All three PRs address preventing infinite retry loops by introducing caps on retry attempts. PR #29047 appears to be addressing the same problem at a different layer (opencode vs session) with a higher cap (5 vs 3). You may want to check if these efforts should be coordinated or if they're addressing different retry mechanisms.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍