fix(ui): keep a token-holder in the app when the boot restore fails for non-auth reasons

[argszero]

Summary

A refresh on a slow instance could land the user on the login page while their token was still in storage — the classic "I got logged out" illusion. The boot session restore treated every non-401 failure of GET /api/me as "not signed in":

try { await loadSession(); enterApp(); }
catch (e) { if (e.status !== 401) toast(T("login.session.fail")); }   // ← stays on the login page

Host report (2026-09-14 21:00): with the transactions aggregate crawling, /api/me was dragged to a gateway 504, and every refresh of #/sharing stopped on the login form with the URL hash still at #/sharing and the token still present — three symptoms that together read as "kicked out".

Related Issue

Host rant 2026-09-14T21:15:02 (aitokenpool), acceptance item 4 — the last of the four. Items 1–3 landed as #240 / #243 / #242.

Changes

• ui/js/app.js: the boot IIFE now only does if (api.getToken()) await restoreSession();, and the new restoreSession() splits the outcome three ways — only the first means "not signed in":
  • 401 → api.js has already cleared the token and returned to the login page; never retried (retrying cannot make a dead token valid);
  • network error / 5xx (incl. 504) → retried once after 1 s, then the app is entered anyway with a "session data failed to load" toast;
  • other 4xx → not retried (pointless), but still enters the app.
• ui/js/i18n.js: login.session.fail no longer says "please sign in again" — a user who still holds a token is not signed out.
• src/i18n_pack.rs: new test session_failure_copy_does_not_claim_the_user_is_logged_out pins the copy rule (the two copies must differ; the load-failure copy must not read like a re-authentication demand), with a synthetic positive/negative control on the detector.
• ui/README.md: records the invariant and the smoke-test shape.
• ui/index.html: cache-bust i18n.js / app.js.

Deliberately not changed: the backend 401 semantics (POST /api/auth/login and change-password use 401 for "these credentials are wrong" — a separate front-end issue), and the login submit path (there the user has just acted and can retry by submitting again; boot has no such out, which is why it is the one that had to be fixed).

Tests

• cargo test — 257 passed (256 before; +1 new test)
• cargo fmt --check — clean
• cargo clippy --all-targets — no new warnings (the one remaining collapsible_match at src/protocol.rs:662 is pre-existing and does not reproduce on CI's stable toolchain)
• New unit test added (copy rule)

How the JS half was verified

jsdom boots the real ui/index.html + the four real scripts (only fetch is stubbed) and scripts /api/me. Checks, all green on this branch (8/8):

check	/api/me	expectation
A0	200	app shown, login hidden, 1 call, no error toast
A1	— (no token)	login stays, 0 calls
B1	504	app shown, login hidden, token kept
B2	fetch rejects	same as B1
B4	504 then 200	recovers, exactly 2 calls, no error toast
B5	403	1 call (4xx is not transient), still enters the app
B3	401	login shown, token cleared, 1 call (unchanged)
D1	504	degraded copy ≠ 401 copy, and never demands re-authentication

A/B legs, each measured on its own source (the working tree was never rewritten; variants were injected by path):

leg	red checks
pre-fix app.js @ 199566c	B1,B2,B4,B5,D1
retry added, but still lands on the login page (the tempting half-fix)	B1,B2,B5
enters the app but never retries	B4
over-reach: enters the app on 401 as well	B3
this branch	none

The half-fix leg is the point: it proves the instrument rejects "just add a retry".

Checklist

• Branch name follows the convention (fix/…)
• Conventional Commits format
• Single responsibility, minimal change