Make session-expiry checks tolerant of client clock skew (derive a server-time offset)

Problem When a user's device clock is wrong, auth-js becomes unusable, and there's no way for the client to compensate. Every session-expiry decision compares the server-issued expires_at against the local device clock (Date.now()). If the device clock runs ahead by more than roughly the token lifetime, each freshly-issued access token is judged "already expired," so the client refreshes immediately, gets another token it also thinks is expired, and loops — until the per-IP refresh rate limit returns 429 and the session wedges. To the user it just looks like "I can't log in," with no hint that their clock is the cause. We hit this in production: one user with a misconfigured OS clock generated 288 refresh tokens across 13 sessions in ~36 minutes, reproduced in two browsers on the same machine. Resyncing their OS clock fixed it. The [User sessions docs]( already acknowledge this ("user devices … can sometimes be off by minut…