fix: 5xx errors from non-standard providers are not retried

[okuyam2y]

Description

MessageV2.fromError currently only upgrades APICallError instances to retryable APIError. When an OpenAI-compatible provider throws a plain Error or object with HTTP status fields instead, the error falls through to NamedError.Unknown, so session retry logic never runs.

Reproduction

1. Configure a custom OpenAI-compatible provider that occasionally returns 502/503
2. The error object may be:
   • An Error with a statusCode or status property (not APICallError)
   • A plain object with status/statusCode or response.status/response.statusCode
   • An Error whose .message is a JSON string containing statusCode
3. OpenCode treats all of these as non-retryable Unknown errors

Expected behavior

Any error with HTTP status >= 500 should be classified as APIError with isRetryable: true, regardless of the error object shape.

4xx handling is unchanged by this fix.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• AI_JSONParseError during SSE streaming is not retried (falls to NamedError.Unknown) #13579: Same root cause — errors that are not APICallError fall through to NamedError.Unknown in fromError() and are not retried (that issue covers AI_JSONParseError, this one covers plain Error with HTTP status fields)
• LLM provider SDK lacks retry logic for transient API errors #11705: Overlapping scope — missing retry logic for transient API errors (5xx, rate limits) from provider SDKs
• Retry transient local provider connection failures (ECONNREFUSED) in session loop #15851: Related — transient local provider connection failures not marked retryable in the session loop

If your issue is specifically about the fromError() classification gap for non-APICallError shapes with HTTP 5xx status, it may be best addressed alongside #13579.

[okuyam2y]

Fix submitted in #19204.