Fix persistent login: /session race + stored brokerOrigin + StrictMode duplicate

[MichielMAnalytics]

Three small fixes for AT Protocol persistent-login. Each commit is self-contained; happy to split if easier to review.

Draft because this is my first contribution against this repo and I'd love a sanity check before marking ready.

---

1. fix(broker): serialize concurrent /session calls per broker_token

AT Protocol refresh tokens are single-use: the PDS rotates the refresh_token on each /token call and immediately invalidates the previous one. The broker stores the rotated value, so serial /session callers each read the latest token and rotate again.

Concurrent /session calls for the same broker_token break this:

• Both callers read the same refresh_token R from the DB.
• Caller A wins at the PDS: gets new token R', broker stores R'.
• Caller B sends R: PDS replies invalid_grant "Refresh token replayed". Broker returns 502 to B without touching the DB.

The web client retries /session once on 502, and React 18 StrictMode's effect double-invocation means each refresh fires the /session effect twice in parallel — kicking the race off again. After a few rounds the stored refresh_token has been rotated to a value the PDS has since invalidated, and every subsequent /session returns 502 forever — the session is bricked until full re-OAuth.

Fix: a per-broker_token Mutex in BrokerState. Concurrent callers for the same token queue on the same Mutex, so the second one sees R' (already rotated) instead of racing on R. Different broker_tokens are independent, so /session concurrency across users is preserved. Bounded with an opportunistic GC pass (entries with Arc::strong_count == 1 get dropped on the next /session call), so session_locks stays proportional to concurrent refresh callers rather than the cumulative set of tokens served.

Also adds tracing::info!/warn! on the /session path so this kind of failure is visible without source diving.

Repro before patch: open the web client, log in via AT Protocol, refresh the page twice. Second refresh shows the login screen; broker log shows Refresh token replayed followed by permanent Invalid refresh token until you re-OAuth.

2. fix(web): ignore stored brokerOrigin equal to webOrigin

ConnectScreen initialises brokerOrigin from localStorage unconditionally. The broker session-refresh effect, however, treats a brokerOrigin equal to webOrigin as "no external broker — server handles auth directly" and short-circuits without calling /session, silently dropping persistent login.

This strands any user whose previous session ran in single-server mode: even after the deployment grows a real broker, the stored value wins the precedence check and refresh never works again, forcing manual localStorage cleanup. Treat stored === webOrigin as absent so the broker-derivation rules below get a chance to run.

3. fix(web): in-flight guard against parallel /session calls

Belt-and-suspenders with #1. Once the broker handles concurrent callers correctly, the SPA itself still fires two /session calls per refresh (React 18 StrictMode double-invokes the effect in dev). Both now succeed thanks to the broker mutex, but each invokes setSaslCredentials + connect(), causing a visible "Establishing session" flash mid-load when the second response lands.

A module-level sessionRefreshInFlight flag — same pattern as the existing oauthConnectInProgress next to it — short-circuits the duplicate before the fetch. Reset in .finally() so failures don't permanently block future refreshes. The broker mutex remains the source-of-truth defence; this is just the SPA being a well-behaved caller.

---

Test plan

• Reproduced the /session race with React StrictMode + two quick refreshes; observed Refresh token replayed → permanent 502s in broker log.
• With all three patches applied, completed AT Protocol OAuth end-to-end on a fresh local clone and refreshed the page 20+ times — single PDS round-trip per refresh, no login-screen fallback, no mid-load flash.
• Existing tests still pass (couldn't run the full suite locally — would appreciate CI confirmation).
• Broker /session behaviour unchanged when calls are serial (per-token mutex is uncontended in that case).