Expose retry policy / max retry controls for API retries

## Feature request

Please expose SDK-level controls for API retry behavior in `query()` / `startup()` options, especially a configurable max retry count and/or a way to short-circuit retries by status code.

## Motivation

The SDK/Claude Code currently emits `system` messages like:

```json
{
"type": "system",
"subtype": "api_retry",
"attempt": 1,
"max_retries": 10,
"retry_delay_ms": 555.8767334129403,
"error_status": 401,
"error": "authentication_failed"
}
```

For transient errors, retrying internally is useful. But for deterministic errors such as `401` / `402` / `403`, waiting for all internal retries can delay application-level recovery. In our use case, we run a long-lived desktop agent with multiple configured LLM providers. When one provider returns an auth/billing failure, we want to immediately fall back to the next provider rather than wait through all SDK retries.

Today, I could not find a public `Options` field such as `maxRetries`, `retryPolicy`, or `shouldRetry` in `@anthropic-ai/claude-agent-sdk` to control this behavior.

## Proposed API

Any of these would work:

```ts
query({
prompt,
options: {
maxRetries: 0,
},
});
```

or:

```ts
query({
prompt,
options: {
retryPolicy: {
maxRetries: 2,
retryOnStatus: [429, 500, 502, 503, 504, 529],
},
},
});
```

or a callback:

```ts
query({
prompt,
options: {
shouldRetry(error, attempt) {
if ([401, 402, 403].includes(error.status)) return false;
return attempt < 3;
},
},
});
```

Ideally the same control would apply to both `query()` and `startup()` / warm query initialization, since warm startup also bakes provider/auth configuration into the child process.

## Alternative

If retry policy is intentionally not configurable, another useful option would be to surface auth/billing failures as terminal stream errors immediately, while keeping automatic retries for transient network/rate-limit/server errors.

## Why this matters

Applications embedding the SDK may have their own provider fallback, credential refresh, or circuit-breaker logic. A fixed internal retry count makes these higher-level recovery strategies slower and harder to reason about, especially for non-retryable auth failures.