fix(accounts): bring an API-key account back after a 401 instead of benching it for good

[MagicalTux]

Fixes #473.

#439 stopped the 401 loop by taking an account out of rotation on its first 401. For an apikey account nothing ever brought it back: the revalidation probe skips error accounts and nothing else re-checks a key, so a gateway that answered a single 401 while its own upstream was down benched a working fallback for 22 hours.

An API-key 401 is now a cooldown rather than a permanent error:

• the request still fails over as before (the client never sees the 401);
• the account is held for 1 min, then 5 min, 15 min and 1 h for every further rejection with no success in between; 401s from requests already in flight during a hold are not counted, so one bad minute does not run straight to the ceiling;
• any response below 400 clears the hold and the count; a 429 or 5xx says nothing about the key and leaves it;
• the hold is respected by selection, by the revalidation probe and by the soonest-reset fallback, so a revoked key costs one failed-over request per cooldown and never loops;
• a reload that brings a different key, or disable/re-enable, lifts it at once.

There is deliberately no escalation to permanent error: the 1 h ceiling is what a revoked key costs, while a fallback silently dead for good is what the report is about. OAuth accounts are unchanged (an account with no refresh token still goes to error).

getStatus exposes credentialRejectedUntil and unavailable: 'credential'; teamclaude status and the dashboard show the reason and the retry time, and the hold counts toward the synthetic 429's retry-after. Documented in docs/accounts.md.

Tests: test/apikey-401-cooldown.test.js (10 tests: first 401 holds and returns after the cooldown, escalation, success reset, in-flight 401s not counted, OAuth unchanged, not selected or probed while held, reload/re-enable lift it, status fields); two existing assertions that expected error for an API key now expect the hold.

🤖 Generated with Claude Code