Subscription-quota 429s are retried, burning the user's quota window #32120

Summary

When a subscription-auth provider returns a 429 because the user's
subscription quota is exhausted (not a transient per-second rate limit), the
retry path treats it like any other retryable rate-limit and retries. Each retry
hits the same exhausted quota, so it can't succeed — it only spends more of the
user's already-depleted window and delays the clear "wait for reset" signal the
user needs to see.

This affects any subscription-auth user, not a single routing setup: a
quota-exhaustion 429 is fundamentally non-retryable until the quota resets, and
retrying is strictly harmful.

Distinguishing quota-exhaustion from transient rate-limit

A transient rate-limit 429 carries a retry-after / retry-after-ms header (or
a structured error code/error body) and should be retried. A
subscription-quota 429 has no retry-after header and a plain
{ detail: "...rate limit..." }-style body. The classifier keys on exactly that:
429 + no retry-after header + no code/error field + a detail string
matching /rate limit/i ⇒ quota exhaustion ⇒ isRetryable: false with a
user-facing "Subscription quota exhausted — wait for your quota to reset" message.

Affected code

• packages/opencode/src/provider/error.ts — parseAPICallError / the retryable
  classification; quota-exhaustion 429s currently fall through to the generic
  retryable path.

Reference implementation

Implemented and test-covered downstream (isSubscriptionQuota429() guard in
error.ts + test/session/retry.test.ts). Happy to open a PR.