fix(keychain): keep using a valid connector token when its refresh fails

[koreankop]

Summary

A connector token refresh fires as soon as the token enters the refresh margin, and its result is returned unconditionally. One failed refresh therefore hands the turn nothing — even though the stored token usually has minutes of life left and would have worked fine.

That turns a brief network problem into a credential outage. Observed on a machine waking from sleep with DNS not yet up: a run of [keychain] connector token refresh failed for <host>: fetch failed, tools that then had no token at all, and scheduled work coming back as provider 401s and "needs reconnect" — for grants that were never revoked. Because the orchestrator walks every connector host, a single bad minute takes out the whole set.

This change falls back to the stored token when a refresh fails and the token has not yet reached its expiry skew. The failure is still stamped on the record, so a genuine revocation still surfaces as needs-reconnect the moment the token really expires; the outage window just stops taking working credentials down with it.

No retries, no new knobs, no added latency: the fallback path is the one that was already returning null.

Test plan

node --experimental-test-module-mocks --test test/keychain.test.ts — 45/45 pass, tsc --noEmit and eslint clean. Three new cases:

• refresh throws while the stored token still has 5 minutes: the stored token is returned, refreshFailedAt is recorded, and status does not report needsReconnect (this one fails on main);
• refresh throws and the stored token is inside the expiry skew: nothing is returned and status reports needsReconnect;
• refresh succeeds: the fresh token still wins over the stored one.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}