fix(web): confirm session before rendering and recover concurrent 401s

[thedancingdeveloper]

Summary

Fixes two UI bugs with one root cause: the SPA trusted any access token in localStorage, but the server keeps tokens in memory (15 min TTL, wiped on restart).

1. Slow initial table population. After token expiry every startup request (/queue, /status, /history, /config/servers, /config/categories) 401s together. Only the first refreshed and retried; the rest waited for their next poll (2s/5s) or never retried (servers, categories).

• All concurrent 401s now share one in-flight refresh, then retry.
• A request sent with an already-rotated token retries with the current one without spending another single-use refresh token.
• The interceptor attaches the current token when a request has none.
• Token expiry is persisted; an expired token is refreshed up front on load.

2. Unauthenticated user briefly sees content before the login bounce. The guard passed on a stale token, so the chrome and Downloads page rendered until the API rejected it; chrome also tracked auth via a 2s localStorage poll.

• authGuard confirms the session with the server once per page load (refresh if expired, else probe /api/status) and redirects via UrlTree if rejected.
• Chrome follows a reactive session signal, and /login + /welcome stay full-screen.
• The login page uses the same check, so a stale token no longer leaves it stuck on "Checking status…".

Trade-off: a cold page load waits one extra round trip before the first protected view renders.

Testing

• npm test -- --watch=false: 100 passed (new regression tests for shared refresh, concurrent 401 recovery, non-auth retry failure keeping the session, guard redirect, stale-token clearing, bare routes)
• npm run build -- --configuration=production: OK (existing 128-byte style budget warning on queue-view, untouched)
• ./ci/run e2e: 90 passed. An earlier run caught a first-boot /welcome → /downloads race, which the bare-route change fixes.

🤖 Generated with Claude Code