feat: Enhance rate limit error retry for some providers

[KrOik]

Issue for this PR

Closes #

Type of change

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

What does this PR do?

Adds better retry detection for rate limiting errors across different AI providers, especially for non-English error messages.

The current retry logic mainly handles OpenAI errors and relies on the provider's isRetryable flag. This doesn't work well when providers like GLM (智谱) return rate limit errors with custom error codes (e.g., 1302) or Chinese error messages like "请求频率过高" (request frequency too high).

Added isCustomRetryable() function that checks for rate limit signals before falling back to provider-specific logic:

• Checks HTTP status codes like 429 or 503
• Matches common rate limit message patterns (supports both English and Chinese)
• Recognizes provider-specific error codes (GLM 1302, "rate_limit_exceeded", etc.)

The function runs first in parseAPICallError(), so rate limit errors get properly detected regardless of which provider you're using. It's backward compatible since it only adds an OR condition before the existing retry logic.

How did you verify your code works?

Added unit tests in packages/opencode/test/session/retry.test.ts that verify:

• 429/503 status codes are retryable
• Chinese rate limit messages are detected
• GLM error code 1302 is recognized
• Standard error codes like "rate_limit_exceeded" work

All tests pass locally with bun test.

Screenshots / recordings

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, I found one potentially related PR:

PR #10767: fix: retry rate_limit APIError
#10767

This PR appears to address a similar issue around retrying rate limit errors. It may be worth checking if it's still open and whether the current PR (#15858) builds upon or duplicates that work, especially since it focuses on the same parseAPICallError() function area for handling rate limit retries.

All other search results either returned the current PR itself or unrelated PRs about different retry mechanisms (web tools, infinite retry loops, etc.).

[KrOik]

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

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

PR #10767: fix: retry rate_limit APIError #10767

This PR appears to address a similar issue around retrying rate limit errors. It may be worth checking if it's still open and whether the current PR (#15858) builds upon or duplicates that work, especially since it focuses on the same parseAPICallError() function area for handling rate limit retries.

All other search results either returned the current PR itself or unrelated PRs about different retry mechanisms (web tools, infinite retry loops, etc.).

Actually not same. This PR is not a duplicate of #10767, it extends to handle some provider-specific error codes (e.g., GLM's 1302; or the rate limitation) and non-English rate limit messages (e.g., Chinese "请求频率过高") that the original fix didn’t cover.