fix(session): retry on 5xx errors from non-standard provider error types

[okuyam2y]

Issue for this PR

Closes #19203

Type of change

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

What does this PR do?

MessageV2.fromError 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 and session retry never runs.

This adds a fallback status extractor for non-APICallError inputs and classifies 5xx responses as retryable APIError. Covered shapes: top-level status/statusCode, nested response.status/response.statusCode, JSON-encoded error messages carrying those fields (with inner message extraction), and plain objects with the same properties.

A file-local ErrorWithStatus interface is used instead of as any casts, following the existing FetchDecompressionError pattern. 4xx handling is unchanged.

How did you verify your code works?

• 8 new unit tests in message-v2.test.ts covering all extraction paths and negative cases (4xx, no status)
• All 30 message-v2 tests and 19 retry tests pass
• bun typecheck passes across all packages

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:

Potential Related PRs

Found 2 related PRs that address similar retry logic issues:

1. PR fix(retry): retry transient 429 responses even when provider marks non-retryable #18443 - fix(retry): retry transient 429 responses even when provider marks non-retryable

   • fix(retry): retry transient 429 responses even when provider marks non-retryable #18443
   • Related: Also addresses retry behavior for provider error responses, specifically for 429 status codes

2. PR fix: retry on AI_TypeValidationError from provider 5xx responses #16228 - fix: retry on AI_TypeValidationError from provider 5xx responses

   • fix: retry on AI_TypeValidationError from provider 5xx responses #16228
   • Related: Handles retrying on 5xx errors from providers, similar error classification strategy

These PRs are not exact duplicates but address the same general area (session/retry error handling for provider responses). You may want to review them for potential conflicts or ensure consistency in the retry logic approach.

[github-actions]

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

[okuyam2y]

Rebased onto latest dev and squashed into a single commit. All 28 message-v2 tests pass, typecheck clean.

Changes from previous version:

• Adapted to upstream's errorMessage() helper (added in recent commits)
• Squashed 3 commits into 1 for cleaner history

Would appreciate a review when you get a chance. Happy to address any feedback.