fix(session): make retry cap and backoffDelay configurable per provider

[eyalatox]

Issue for this PR

Closes #21960

Type of change

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

What does this PR do?

Follow-up to #41939, which added the fixed RETRY_MAX_RETRIES = 5 cap. That default is right for most cases, but the retry budget users want differs per provider (an aggressive retry loop against a rate-limited Bedrock account makes things worse; a flaky self-hosted proxy may need more than 5). This PR makes the cap and the initial backoff configurable per provider:

{
  "provider": {
    "amazon-bedrock": {
      "options": { "retry": 3, "backoffDelay": 1000 }
    }
  }
}

• retry — max attempts (default 5 from fix(opencode): cap session retries with jitter #41939, 0 disables retries)
• backoffDelay — initial backoff in ms (default 2000); provider retry-after headers still take precedence, and the jitter from fix(opencode): cap session retries with jitter #41939 is preserved

Both options are stripped before SDK construction (like chunkTimeout) so they never reach the provider client.

How did you verify your code works?

• Rebased on current dev (keeps the fix(opencode): cap session retries with jitter #41939 jitter + cap behavior and its tests intact).
• New unit tests in test/session/retry.test.ts: retry raises/lowers the cap; retry: 0 never retries; backoffDelay changes the backoff progression; retry-after headers still win. bun test test/session/retry.test.ts → 59 pass.
• bun run typecheck clean in packages/core and packages/opencode.
• Regenerated SDK types via ./script/generate.ts.

Screenshots / recordings

N/A (no UI change)

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:

Based on my search results, I found one potentially related PR:

PR #38958: fix(session): cap retry attempts to prevent infinite thinking on API errors
#38958

This PR appears to address a similar issue of capping retry attempts to prevent infinite sessions on API errors. It may be worth reviewing to see if it's a prior attempt at fixing the same problem or if it's been superseded by PR #41699.

All other results in the search were either PR #41699 itself or unrelated retry handling fixes. No other duplicate PRs were identified.

[eyalatox]

Re the duplicate check: #38958 hardcodes a cap of 5 (single file, no tests). Since #41939 merged the fixed cap upstream, this PR is now rebased on it and adds the per-provider knobs: configurable retry (0 disables) and backoffDelay, with tests, docs, and schema/SDK updates.

[github-actions]

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