[afonsoft]

Summary

Closes #14960.

• With useUpstream429BreakerHints on, quota_exhausted maps to a fixed cooldownByKind override (3.6M ms) — but CircuitBreaker._effectiveCooldown() returned that override before the openCycleCount escalation ran, so failed HALF_OPEN probes kept bumping the cycle count while the next cooldown stayed 1h. A provider whose quota resets once a day got probed every hour all day.
• The per-kind override now receives the same 2^(openCycleCount - backoffEscalationCount) escalation the base resetTimeout gets, capped at override * maxBackoffMultiplier (so quota_exhausted backs off 1h → 2h → 4h … up to 16h). Kindless failures are unchanged — they still escalate the base resetTimeout only.
• providerCircuitOpenResponse accepts an optional failureKind and surfaces it as error.failure_kind on the 503 body; the three chatHelpers call sites pass breaker.getStatus().lastFailureKind. Operators can now tell a quota_exhausted breaker (long upstream reset) from a generic rate_limit one without reading server logs.

Test plan

• tests/unit/circuit-breaker-kind-cooldown-escalation-14960.test.ts — 3/3 (override escalation curve + cap, kindless path unchanged, failure_kind on/off)
• tests/unit/circuit-breaker-failure-kind.test.ts — 15/15 (existing [BUG] Circuit breaker: differentiate 429 rate-limit vs quota-exhausted #2100 per-kind cooldown coverage still green)
• npm run typecheck:core — clean
• eslint on changed files — no new errors (5 pre-existing on base)

⚠️ base-red inherited: #14963 (release/v3.8.51 tip has unrelated HARD gate failures; no overlap with this change)

Maintainer rework (merge-batch 2026-09-28 (release drain))

• Merged release/v3.8.51 into the branch (real merge, no rewrite).
• Prettier on circuitBreaker.ts / chatHelpers.ts.
• The three circuit-open call sites in chatHelpers.ts now go through one breakerOpenResponse(provider, breaker, retryAfterSec) helper so each stays on a single line.
• Recorded the remaining own growth (error.ts 1219->1221, chatHelpers.ts 1279->1285) as a dated frozen entry in config/quality/file-size-baseline.json.

[afonsoft]

Detalhamento da correção (#14960)

Root cause

Com useUpstream429BreakerHints ligado, quota_exhausted mapeia para um cooldown fixo de 3_600_000 ms via cooldownByKind (chatHelpers.ts:362, accountFallback.ts:1163). O problema: CircuitBreaker._effectiveCooldown() (src/shared/utils/circuitBreaker.ts) retornava o override antes de aplicar o escalonamento — cada probe HALF_OPEN que falha incrementa openCycleCount, mas o próximo cooldown continuava 1h. Um provider com quota diária era sondado de hora em hora o dia inteiro.

Mudanças

1. circuitBreaker.ts::_effectiveCooldown() — o override per-kind agora recebe o mesmo escalonamento do resetTimeout base: 2^(openCycleCount - backoffEscalationCount), com cap em override * maxBackoffMultiplier (quota_exhausted: 1h → 2h → 4h → … → 16h máx). Escolhi a primeira opção sugerida na issue (escalonar o override, não seguir o hint upstream verbatim) porque um probe que falha prova que o hint estava errado — backoff exponencial é a resposta correta. Falhas sem kind continuam no path antigo (_effectiveResetTimeout).
2. open-sse/utils/error.ts::providerCircuitOpenResponse — aceita failureKind opcional e emite error.failure_kind no body do 503 (ponto levantado na issue).
3. chatHelpers.ts — os 3 call sites passam breaker.getStatus().lastFailureKind.

Testes

tests/unit/circuit-breaker-kind-cooldown-escalation-14960.test.ts (3 casos): curva de escalonamento do override (flat até backoffEscalationCount, dobra depois, cap), path kindless inalterado, failure_kind presente/ausente. Os 15 testes de circuit-breaker-failure-kind.test.ts (#2100) seguem verdes.

cc @diegosouzapw — pode revisar?