feat(providers): add expiry-first account fallback strategy

[feci]

Problem

A provider with several accounts can rotate them with fill-first, round-robin, priority,
p2c, random, least-used, cost-optimized or strict-random. None of these considers when
an account's quota window resets, so fill-first — the default — drains the top-priority account
while the others sit full until their windows roll over and the unspent quota is lost.

Observed on a four-account Codex pool over 14 days:

priority	calls	input tokens
1	4605	630.7M
2	2147	264.8M
3	1779	229.8M
4	203	25.3M

At the time of measurement priority 1 held 26% with ~145h to reset, while priority 4 held 88% with
~69h to reset. The account about to lose the most quota was the one barely being used.

What this adds

expiry-first, a per-provider account fallback strategy that spends the quota closest to being
lost. Each account is ranked by how much it must burn per hour to avoid wasting its leftover:

score = usable / hoursUntilNearestReset

• usable is the tightest window's remaining fraction. Nested windows (a session cap inside a
  weekly one) decrement together, so an account can never spend more than its most constrained
  window allows.
• The deadline is the nearest reset, because that is when the first tranche is lost.
• An exhausted account scores zero, so it never wins on a near reset alone. That is why plain
  earliest-deadline-first is the wrong rule: on the pool above it would pick the 1%-remaining
  account purely because it resets in 8h.

On that pool: 0.26/145 = 0.0018, 0.88/145 = 0.0061, 1% excluded, 0.88/69.3 = 0.0127 → the last
one is selected, which is the account whose quota was about to expire unused.

Why not extend reset-aware

scoreResetAwareQuota answers a different question. It ranks mostly on leftover and adds
resetUrgency * (1 - remaining) — a recovery signal that favours a nearly empty account about
to refresh. Its urgency term is also relative to the nominal window length and clamps to zero
outside it, so for the two 88% accounts above it returns the same score (0.341725 each) and
cannot separate a 69h reset from a 145h one. Both strategies are useful; they are not the same
strategy, so this adds one rather than changing the meaning of the existing one.

Scope and safety

• Ordering only. The strategy ranks accounts the existing quota, rate-limit and peak-hour filters
  have already allowed; it adds no upstream quota call (it reads the per-connection quota cache).
• Session stickiness and prompt-cache affinity are untouched.
• Accounts within expiryFirstTieBandPercent (default 5%, compared relatively since the score is a
  rate) rotate least-recently-used, so equivalent accounts still share load instead of pinning.
• Falls back to the incoming priority order when no account reports quota telemetry.
• New tunables, all defaulted: expiryFirstTieBandPercent, expiryFirstMinHours,
  expiryFirstExhaustedFloorPercent.

Tests

tests/unit/expiry-first-account-rotation.test.ts — 10 cases covering the ranking, the
equally-full-different-reset case, exhausted-account exclusion, tightest-window binding, tie
rotation, backoff skip, the no-telemetry fallback and the empty pool. The ordering is a pure
exported function with an injected quota lookup, so it needs no database or network.

Also ran the 25 existing quota/strategy/fallback unit test files: 213 passing, 0 failing.

[diegosouzapw]

Nice addition — the reset-pressure framing (score = usable / hoursUntilNearestReset) is a
clean generalization of the existing reset-aware/reset-window pair, and the 10-case test
suite is solid (ran it locally, 10/10 pass). One gap before merge: docs/routing/AUTO-COMBO.md
still says "19 routing strategies" and its strategy table doesn't list expiry-first yet —
could you add it there? Also flagging: the changelog fragment is named
14381-expiry-first-account-rotation.md — is #14381 the right issue number, or should that be
#14533?