fix(agent): heal credential-pool last_status after a successful served request

[SayHell0W0rld]

Summary

Fixes gap 2 of #95166: a credential-pool entry marked STATUS_EXHAUSTED by a transient wall stays exhausted after the wall lifts, making every subsequent pool reader see a false wall.

Approach

• _mark_healthy() (agent/credential_pool.py) — symmetric to _mark_exhausted(): resets last_status to STATUS_OK and clears error fields. No-op when the entry already has last_status=None.
• _relay_final_response() (agent/chat_completion_helpers.py) — the unified success exit for chat-completions mode: after a successful served request, heals the active credential-pool entry if it still carries a stale exhausted/dead verdict.
• Only chat-completions mode is covered by the success-side heal; other API modes (responses, streaming-only) are not yet wired — the issue's reported probe path uses chat-completions, so this closes the gap for the primary case.

Test Plan

• 3 new tests in test_credential_pool.py: TestMarkHealthy — clears exhausted status, skips already-healthy entry, clears dead status.
• Full file: 62/62 pass (3 new, 59 existing). ruff check clean. Windows footgun lint clean.

Risk / Exclusions

• _mark_healthy is provider-agnostic and only touches the shared credential pool.
• _relay_final_response only runs for chat-completions mode; other API modes (responses, streaming-only) are unaffected.
• No prompt-cache or message-alternation impact (the heal runs after the response is fully constructed).

References #95166

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Plugs a real gap: nothing else in agent/ clears an exhausted/dead verdict after the provider actually serves traffic (the only other STATUS_OK writes are refresh/import paths inside credential_pool.py itself). Observations:

• chat_completion_helpers.py:4028-4036 — match-by-runtime_api_key is the right identity (not entry id): it survives pool re-imports that re-phase credentials, and healing every duplicate entry sharing the key is correct. Gating on (STATUS_EXHAUSTED, STATUS_DEAD) at the call site keeps the hot path cheap.
• Coverage question, worth a maintainer answer: _relay_final_response is the Relay streaming path's finalizer (relay_llm.stream at :3349/:3376). The non-streaming success path in the same module has no equivalent hook — a key that only ever serves non-streaming requests stays stuck at its stale verdict. If xai-oauth: usage/limits visibility parity with openai-codex (fetch_usage), and heal credential_pool last_status on served requests #95166's repro was streaming-only that's defensible, but the intent ("successful served request") implies both; either extend or add a note documenting the asymmetry.
• credential_pool.py:918-935 — _mark_healthy's early-return covers only last_status is None; a direct call on a STATUS_OK entry still does _replace_entry + _persist (a no-op disk write). The call site pre-filters so this is unreachable today, but test_skips_already_healthy_entry pins that run — either early-return on STATUS_OK too, or make the test assert the intended no-op rather than the current replace-and-persist.
• Observability nit: a stale-dead → ok recovery is a meaningful state transition (a flapping key will flap this branch); nothing is logged when it fires, unlike the pairing _mark_exhausted path. One logger.info("cleared stale %s verdict for %r", ...) would pay for itself the first time someone debugs pool hysteresis.
• Tests cover the three transition shapes (exhausted→ok, dead→ok, already-ok) with full field-level assertions including last_status_at/last_error_code clears. The new method isn't included in the file's existing "does not hold the lock" deadlock test class above (line ~2079) — arguably worth adding for symmetry since it persists under the same locking regime.

No blocking issues found; the streaming-vs-non-streaming coverage gap (second bullet) is the one to resolve before merge.

[SayHell0W0rld]

Merged into #90417 (both fixes live in _relay_final_response's success path; keeping one PR avoids a merge conflict between two overlapping edits of the same function). The reasoning-recovery and credential-heal logic are both preserved on the combined branch.