Summary

On plain HTTP origins, navigator.locks is unavailable and session refresh fails. Keep the existing Web Locks/BroadcastChannel flow where supported and use a SharedWorker otherwise. The worker owns the refresh request and shares its result across tabs, avoiding concurrent use of the backend's single-use refresh token.

The fallback uses a separate Connect client with cookies and no UI interceptors. Same-tab callers share one promise. The client waits for the worker readiness handshake before dispatching a refresh. Startup errors and timeouts close the unused port and retry within the same shared refresh promise, up to three attempts with 250 ms and 500 ms delays. If startup retries are exhausted, the auth interceptor returns temporary unavailability without expiring the session; later API requests can retry startup throughout a longer rollout. Failures or timeouts after readiness require reloading the page before trying the worker again. The worker refresh RPC has no client deadline: the page watchdog gives startup and the dispatched refresh separate 35-second intervals, and rejects waiting callers without aborting an in-flight token rotation. Backend token rotation is unchanged, with no grace period.

This is an independent alternative to #21616; that PR is unchanged.

Validation

• pnpm --dir frontend fix and pnpm --dir frontend test pass: guards, Biome, TypeScript, production bundle, and 586 test files / 6,614 tests.

• Added tests for Web Locks selection, fallback selection, concurrent worker ports, rotations lasting beyond the page watchdog without starting a second request, shared failures, later refreshes, recoverable worker startup errors and timeouts, a full refresh watchdog interval after slow startup, terminal failures after readiness, stale worker errors, and unavailable SharedWorker.

• Chromium verification using the built fallback on a LAN HTTP origin (isSecureContext === false, no navigator.locks) against a simulated single-use refresh endpoint: two tabs produce one request, both succeed, the next rotation uses the replacement HTTP-only cookie, and closing the initiating tab does not interrupt the remaining tab's refresh.

• No full Bytebase browser E2E run; the browser endpoint above was simulated.

• Review follow-up: Chromium verification with a production-built worker and a simulated old-replica HTML response confirmed that a single refresh call survives the initial HTML response: two worker loads produce exactly one refresh request. Interceptor regression tests verify that recovery and repeated startup retry exhaustion do not set the session-expired flag or show a reauthentication notification, and that a later request recovers once the worker becomes available.

Compatibility and limits

HTTP fallback requires SharedWorker with module-worker support. Unsupported or blocked workers fail explicitly rather than issuing competing requests. HTTPS/localhost deployments retain the existing Web Locks path. Lost responses after server-side rotation can still require reauthentication, as before.