test(auth): pin the over-age token asymmetry the interceptor reacts to

[lidonius1122]

The reproduction from #2981, as a test.

refreshToken() is the only reader of sessionStartedAt, so a token past the 30 day cap is refused a renewal while /auth/check still accepts it. That asymmetry is what let the interceptor turn a refused refresh into an account-wide logout the server then honoured. The fix for that is in the interceptor and refreshSession(); this pins the server side they react to.

The 31 days are a backdated sessionStartedAt rather than elapsed time, so it tests the comparison and nothing about clocks.

I also wrote a second test around the logout itself, over-age token revoking the account and scope: 'local' sparing the other device, and dropped it. /auth/logout never reads sessionStartedAt, so nothing in it depended on the token being over-age; it passed just as happily with a fresh one, and its account-wide half duplicated keeps other sessions alive when the logout is scoped to this browser.

Ran the original chain against a beta.3 instance as well, driving the real interceptor rather than a mock: {"scope":"local"} on the wire, second device still 200. Reverting both halves of c903c0a in a scratch copy puts {} back and takes it to 401.

62 passing in the auth e2e file, lint clean. Adding the cap to validateUser() fails this test and nothing else in the suite; disabling it in refreshToken() fails this plus refuses to renew a session past its maximum age and warns when it refuses a refresh, and stays quiet when it allows one. The maximum age assertion is there because a 401 from an expired or malformed token would otherwise satisfy the same expectation.