Account: sign-out races left after #3193 (epoch on every attempt, in-flight link redemption, retry backoff) #3198

Follow-up of #3164 and #3193. #3193 (parked as draft) makes a sign-out win over sign-ins still on their way (a sign-out epoch) and keeps unconfirmed revocations to retry. The merge pass's delta review at ead7c40 reproduced the following on adjacent paths. They need one design pass across the client and the account service instead of more fix rounds on #3193.

1. HIGH: a request made before a sign-out can still run with a later sign-in (src/lib/account/service.ts:498, AccountService.call).
   The sign-out epoch is read when call() starts, but compared only before the 401 retry. A request whose first attempt picks up its session after a sign-out and a new sign-in (same account) runs with that new session.
   Expected: call() captures the epoch with the session it was made for, and refuses to send under any other epoch, on the first attempt as on the retry.

2. HIGH: a link redemption already in flight still adds the identity after a local sign-out whose revoke failed (src/lib/account/signin.ts:97, finishSignIn with bearer).
   The client checks the epoch before redeeming at /v1/token, but a sign-out that lands while that request is in flight cannot stop it. If the sign-out's revoke then fails (429, 5xx or network), the bearer is still valid at the service, and the link commits.
   Expected: the account service binds link redemption to a session that is still valid when it commits (for example, the link token is consumed or refused once that session's family is signed out, or the client's sign-out is acknowledged before redemption). This needs a change in the account service, not only the client.

3. MEDIUM: the retry list for unconfirmed revocations ignores Retry-After and has no storage bound (ending in src/lib/account/service.ts and store.ts).
   Every account screen load and sign-out retries every entry right away, also after a 429 with Retry-After, which spends the account's request limit. The list has no cap or age limit, so refresh tokens can stay in IndexedDB indefinitely when the service stays unreachable.
   Expected: back off per entry (honouring Retry-After), and bound the list (drop entries past the refresh token's lifetime, since they no longer redeem) without silently dropping a revocation that could still matter.