fix(gateway): preserve retry semantics when APICallError is converted to GatewayError

[giulio-leone]

Summary

Fixes #14216

When @ai-sdk/gateway converts an APICallError into a GatewayError subclass (via asGatewayError()), the SDK retry logic no longer recognizes the error as retryable because APICallError.isInstance() returns false for GatewayError. This causes maxRetries to be silently ignored for transient 503, 429, and 408 gateway failures.

Root Cause

The retry logic in retry-with-exponential-backoff.ts only checked APICallError.isInstance(error) && error.isRetryable. After asGatewayError() wraps the original APICallError into a GatewayError subclass, APICallError.isInstance() returns false, so the error is never retried.

Changes

@ai-sdk/gateway

• Added isRetryable field to GatewayError base class with the same default logic as APICallError (408/429/500+ are retryable)
• Updated all 7 GatewayError subclasses to accept and forward isRetryable
• Updated createGatewayErrorFromResponse() to accept and forward isRetryable
• Updated asGatewayError() to propagate isRetryable from the original APICallError

ai (core)

• Updated retry logic to recognize both APICallError and GatewayError as retryable error types
• Added getResponseHeaders() helper to extract retry-after headers from GatewayError's cause chain (the original APICallError is preserved as cause)

Test Coverage

• 10 new tests for isRetryable defaults across all GatewayError subclasses
• 3 new tests for isRetryable propagation from APICallError through asGatewayError()
• 8 new tests for gateway error retry behavior in the retry logic (retryable errors, non-retryable errors, retry-after header extraction, maxRetries limit)
• All 392 existing gateway tests pass
• All 20 retry tests pass (11 existing + 8 new + 1 updated)