fix(admin): floor the silent-refresh delay so it can never hot-loop (#323)

[jayesh-keychain]

msUntilRefresh clamped to 0:

Math.max(0, exp * 1000 - skewSeconds * 1000 - nowMs)

Whenever a token's remaining life was shorter than the 60s skew that returned 0, the scheduler called setTimeout(…, 0), the refresh minted another equally short-lived token, and the next delay was 0 again. Not a retry — an unbounded tight loop: ~180 req/s, 32,915 calls to /auth/refresh in a few minutes, every one returning 200, churning a refresh-token row each time via single-use rotation.

Fix — two changes, both about never scheduling zero:

• MIN_REFRESH_DELAY_MS floor (5s) — a pathological case becomes slow rather than hot, whatever the arithmetic does.
• The skew adapts: min(60s, remainingLife / 2). Reserving a fixed 60s of a 15s token marks every refresh permanently overdue, which is what starts the loop.

TTL	next refresh
900s (production)	840s — unchanged
60s	30s
30s	15s
15s	7.5s (was: 0, looping)

Correction to the issue as filed

#323 claimed this bites in production ~15 minutes after sign-in at JWT_ACCESS_TTL=900. That is wrong. At 900s the scheduler fires once at 840s and reschedules normally — no loop. It requires a TTL at or below the 60s skew, which I had set myself while testing #318. Still a real robustness defect, but not the production incident described — issue corrected and downgraded P0 → P2.

Verification

• 13 tests pass, incl. 5 new regression tests: the loop condition, adaptive skew, expired token, unparseable token, and production delay unchanged
• An existing test asserted toBe(0) for a 30s token — it encoded the buggy contract, so it is updated, not worked around
• type-check + lint green

Closes #323.

🤖 Generated with Claude Code