fix(auth): scope Codex quota cooldown clearing by token

[dhansxd]

What does this PR do?

Keeps Codex quota recovery scoped to the credential whose quota was actually
confirmed restored.

The early-reset recovery added in #69494 already accepts an optional
access_token in clear_codex_pool_quota_cooldowns(), but its two runtime
callers omitted that argument. In a multi-account credential pool, a positive
usage probe or successful reset redemption for account A therefore cleared
the persisted 429 cooldown for unrelated account B as well. If account B was
still at 100% usage, it re-entered rotation only to fail and be quarantined
again.

Related Issue

Follow-up to #69494 and the multi-account behavior reported in #43747.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• hermes_cli/auth.py: pass the positively probed stale_token when clearing
  a stale Codex pool cooldown.
• agent/account_usage.py: pass the token used for a successful /usage reset
  redemption.
• tests/hermes_cli/test_auth_codex_quota_probe.py: cover a two-account pool
  containing a separate manual:device_code credential that must remain
  exhausted.
• Clarify that unscoped clearing is reserved for an explicit whole-pool
  administrative reset.

How to Test

1. Create two exhausted openai-codex pool entries with different access
   tokens.
2. Confirm quota recovery or redeem a reset for only the first token.
3. Verify the first entry is unfrozen while the unrelated entry retains its
   429 status and future last_error_reset_at.

Before the fix, the two strengthened regressions failed because both entries
were cleared. After the fix:

tests/hermes_cli/test_auth_codex_quota_probe.py: 21 passed
Adjacent auth, account-usage, and credential-pool suites: 230 passed
ruff: passed
git diff --check: passed
Windows footgun scan: passed

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix
• I've run the full pytest tests/ -q suite
• I've added tests for my changes
• I've tested on macOS

Documentation & Housekeeping

• Relevant function documentation was updated
• cli-config.yaml.example update is N/A
• CONTRIBUTING.md / AGENTS.md update is N/A
• Cross-platform impact was considered; the change is platform-neutral
• Tool descriptions/schemas update is N/A

Screenshots / Logs

N/A — credential state is covered by hermetic regression tests; no secrets or
live authentication data are included.

[teknium1]

Thanks for tracing the cleanup scope through both recovery paths. The production premise is confirmed on current main: hermes_cli/auth.py:3916 and agent/account_usage.py:710 both omit the token, while the helper already filters correctly when given one at hermes_cli/auth.py:4157.

Problems

• The regression-test hunks need manual salvage. Current main retains the probe recovery test at tests/hermes_cli/test_auth_codex_quota_probe.py:221, but the reset-redemption section is empty after line 280 following test pruning; the PR's old test locations no longer exist.

Suggested changes

• Port the two-account probe assertion into the current recovery test and recreate the successful reset-redemption two-account regression in a current account-usage or quota-probe test location.

Automated hermes-sweeper review.

[teknium1]

Current main retains this recovery test but has pruned and renumbered it to lines 221-240. Port this two-account assertion into that surviving test during salvage so the token-scoping regression remains covered.

[teknium1]

Current main has no remaining reset-redemption test in this file after its test-pruning change. Recreate this two-account reset regression in a current test location when salvaging the production call change.