fix(resilience): retry Codex pre-output transport failures on the same account (#9708)

[Prudhvivuda]

Summary

• Retry a retryable pre-output transport failure (502/503/504/507, connection reset, retry-buffer overflow) once on the same account after a 2–3s jittered delay, without marking the connection unavailable on the first blip.
• Keeps Codex session/account affinity so a brief proxy reset does not drop the warm prompt-cache partition.
• When the last eligible account is only temporarily unavailable and siblings are quota-filtered, surface a mixed-cause 503 instead of 429 All codex accounts reached configured quota threshold.

Closes #9708

⚠️ base-red inherited: #9985

Test plan

• node --import tsx/esm --test tests/unit/codex-same-account-transport-retry-9708.test.ts
• node --import tsx/esm --test tests/unit/sse-auth.test.ts --test-name-pattern quota
• Confirm a first 503/507 on the last eligible Codex account retries the same connection and succeeds
• Confirm a second consecutive transport failure then cools the account and rotates
• Confirm a quota-filtered pool plus one transport-cooled account does not return the all-quota 429

[diegosouzapw]

Reviewed and validated in an isolated worktree off release/v3.8.50.

Tests: codex-same-account-transport-retry-9708.test.ts — 7/7 pass, including the getProviderCredentials mixed-cause (quota + transport-cooldown) 503 case. Existing sse-auth.test.ts --test-name-pattern quota — 67/67 pass, no regression. eslint clean on all touched files; tsc --noEmit clean.

Circuit-breaker/cooldown interaction: traced this carefully since it touches the resilience layers described in AGENTS.md — no conflict. The same-account retry only exempts the first pre-output 502/503/504/507 blip; a second consecutive failure on the same connection falls through unchanged into the existing markAccountUnavailable() / breaker._onFailure() path, so provider-breaker and connection-cooldown accounting behave exactly as before for genuinely repeated failures. Nice, surgical addition.

Two things worth a quick look before/after merge, neither blocking:

1. Scope: shouldRetrySameAccountTransport / isRetryablePreOutputTransportError and the new mixed-availability 503 branch in auth.ts aren't gated on provider === "codex" anywhere — as written this changes retry/error behavior for every provider, not just Codex, even though the title/issue/changelog all frame it as Codex-specific. Was that intentional (a general resilience improvement, generalized past the original issue), or should it be scoped to Codex? Either is fine, just want to make sure it's a deliberate call rather than an oversight, since it's a behavior change for the other 340 providers with no dedicated test coverage for them.
2. hasEmittedOutput: sameAccountTransportRetry.ts documents and unit-tests a guard against retrying after output has already streamed to the client, but it's never passed from the real call site in chat.ts (confirmed via repo-wide grep). It's harmless today — result.success only goes false pre-stream in the current control flow (the STREAM_EARLY_EOF/stream_timeout branch that would hit mid-stream always exits before reaching this block) — but as written it's a safety param that looks load-bearing and isn't. Worth either wiring it up or dropping it from the signature so it doesn't mislead the next person touching this file.

Also noticed 3 unchecked boxes in the test plan (live-account 503/507 retry, second-failure rotation, mixed-pool 503) — the automated coverage looks solid to me as a substitute, but flagging in case you want to close the loop with a live check per the repo's bug-fix protocol.

Overall: solid, well-scoped fix mechanically. ⭐⭐⭐⭐