Sync login session expiry across browser tabs instead of per-tab countdowns

Each open tab runs its own login-session countdown today. The server keeps only the latest login session, so the timers drift apart: a tab whose local timer runs out raises an `AuthorizationError` from `LoginSessionExtendButton` and navigates the user off the page even though the login session on the server is still alive, while the other tabs keep showing a remaining time that no longer matches the server.

UX-wise all tabs share one session, so they should expire together and be renewed together.

Open question noticed while discussing this: a new tab unconditionally calls `extend-login-session` on boot. That may only exist because the client has no other way to learn the expiry timestamp — confirm before changing the flow.

## Proposal

- Keep the expiry **timestamp** in the jotai atom, not only the expired / not-expired flag that is stored there today.
- Broadcast a renewal to the other tabs. The `storage` event on `localStorage` is the simplest option; `BroadcastChannel` is an alternative worth comparing.
- On receiving the event, refresh the atom so every tab shows the same remaining time and expires or renews as one.
- Decide whether the unconditional `extend-login-session` call on new-tab boot can be dropped once the expiry timestamp is shared.

Investigate and measure the current behaviour first, then implement. A test server with a short login-session expiry is needed to reproduce.

—

Captured while working on branch: main

JIRA Issue: FR-3664

Start at LoginSessionExtendButton, the jotai atom, and the extend-login-session call made when a new tab boots. Reproduce the drift with a test server using a short login-session expiry, then compare localStorage's storage event with BroadcastChannel. Done means tabs share an expiry timestamp, renew together, and expire together without unnecessary boot-time renewal.

Written by the indexing model from the issue text.