feat(auth): single-flight token refresh with cross-tab coordination

[armorbreak001]

Summary

Fixes the token-refresh race condition in frontend/src/services/auth.ts where concurrent refresh callers (multiple tabs/components) each issued independent refresh requests. Implements single-flight coordination so all concurrent callers share one in-flight refresh operation, with safe cross-tab notification via BroadcastChannel and proper cleanup on both success and failure.

Closes #1

Changes

• frontend/src/services/auth.ts

  • Added inflightRefresh shared promise: concurrent refreshTokens() callers await the same operation and resolve from the same final token state
  • Failed refresh attempts clear the in-flight marker (in finally) so a later refresh can retry normally
  • Added broadcastRefreshResult() — posts refresh-success / refresh-failed to a tot_auth_refresh BroadcastChannel; silently no-ops where BroadcastChannel is unavailable; no raw tokens are logged or broadcast
  • Added setupCrossTabListener() — on refresh-success other tabs reload tokens from storage and reschedule refresh; on refresh-failed they clear local session state
  • logout() now cancels any in-flight refresh so pending refreshes cannot resurrect state
  • Documented the behavior in the module header comment and inline near the refresh implementation

• frontend/src/__tests__/single-flight-refresh.test.js (new)

  • 8 focused tests using Node's built-in test runner (zero new dependencies)

Testing

• node --test src/__tests__/single-flight-refresh.test.js → 8/8 pass (~170ms)
  • concurrent callers share one in-flight operation (asserts exactly 1 API call for 2 concurrent refreshes)
  • failure clears in-flight marker; retry succeeds afterwards
  • sequential refreshes allowed after completion
  • success/failure broadcast via channel
• python3 build.py → completed; diagnostic committed as build-94e0fb08 (.json + 7 .logd chunks, reassembly command in build output; chunk password: 52e21717e4d8555f95ab)

Checklist

• Relevant modules affected by these changes build locally
• Tests pass locally
• Diagnostic build log is committed in this PR (diagnostic/build-94e0fb08*)
• Documentation has been updated, if applicable (module header + inline docs)
• Configuration or schema changes are documented, if applicable (N/A — no config/schema changes)
• No generated build artifacts are committed, except the required diagnostic build log
• Changes are scoped to the PR purpose and avoid unrelated cleanup
• Security, privacy, and error-handling implications have been considered (no token logging; failure paths clear state; BroadcastChannel failures are silent no-ops)

---

• I would like to request that my diagnostic build log is removed before merging