fix(openai): retry a transient 429 instead of ending the run

[JumpLink]

Fixes #357.

The problem

Any 429 whose text reads like a spent allowance is never retried. @langchain/core's classifyRateLimitError matches /insufficient[_ -]?quota/i, returns { action: 'stop' }, and defaultFailedAttemptHandler throws before p-retry gets a second attempt. For OpenAI that is right - insufficient_quota means out of credit.

Scaleway answers all three of its rate limits with that wording and nothing else to go on:

HTTP/2 429
content-type: application/json
{"status":429,"error":"INSUFFICIENT QUOTA",
 "message":"You exceeded your current limit of concurrent requests."}

Tokens-per-minute and requests-per-minute differ only in message, which the OpenAI SDK drops - APIError keeps body.error alone - so the classifier only ever sees 429 "INSUFFICIENT QUOTA" and reads a limit that clears in milliseconds as a billing wall. No x-ratelimit-* and no retry-after on the 429 either, although successful responses carry the former.

The fix

An onFailedAttempt handler on the OpenAI-compatible constructors that retries a 429 unless something structured says the allowance is gone:

• error.code === 'insufficient_quota' - OpenAI's billing wall - stop
• wording naming billing, credit balance, out of credits, payment - stop
• a single request larger than the per-minute allowance - stop, and hand it to the existing context-overflow recovery, which shrinks the prompt instead
• LangChain's never-retry statuses and cancelled requests - stop
• everything else - return, so p-retry's randomized exponential backoff runs

The discriminator between the two quota meanings is the underscore: insufficient_quota is OpenAI's error code, INSUFFICIENT QUOTA with a space is Scaleway's rate-limit label. A caller-supplied onFailedAttempt still wins, so nothing that already sets one changes behaviour.

Applied to ChatOpenAI (hence Moonshot and OpenRouter), AzureChatOpenAI, ChatDeepSeek and ChatXAI.

Measured

Against api.scaleway.ai on 2026-07-30, driven through ChatOpenAI from this package with the added probe script (npm run probe:ratelimit):

Load	stock policy	with the handler
150 concurrent 2-token requests	123/150 in 2.5s	150/150 in 3.3s
4 x 30k-token requests (drains a 100k/min bucket)	2/4 in 4.0s	4/4 in 58.3s

The 58s is the token bucket refilling, and that is the trade this makes: a slow turn instead of a dead one. A rejected request is not billed, so the retries cost waiting and nothing else.

Tests

22 unit tests built on real APIError instances generated by the OpenAI SDK rather than hand-written objects, so the assertions run against the shape production sees - including a wiring test that the handler reaches model.caller.onFailedAttempt for all six classes, and that an explicit handler is left alone. src/utils + src/llm/openai: 300 tests green.

The probe script follows context-overflow-probe.ts: it exists so the retry policy stays grounded in what providers send instead of in phrases someone expected them to send.