fix(spa): suppress 401 error toasts during SSO stale-session reload

[awais786]

Summary

When the user switches identity at the portal level (Logout-all → log in as a different user), Outline's `accessToken` JWT cookie is stale until the server's mismatch check (`server/middlewares/authentication.ts:416-424`) fires on the next request and clears it via `err.headers`. The server-side flush is correct, but the SPA shows a flash of "failed to get docs / access tokens" before the implicit reload completes.

Repro

1. Log in to Outline as user A
2. From the portal, click "Log out of all apps"
3. Log in as user B
4. Switch back to the Outline tab — error toast appears briefly before the page reloads with user B's content

Root cause

The SPA's `ApiClient.ts:181-202` handles 401 in SSO mode by:

```ts
window.location.replace(window.location.href);
throw new AuthorizationError();
```

The first 401 triggers the reload. But the page doesn't navigate instantly — and on the first post-switch render multiple API requests are in flight (docs/, access-tokens/, team/, etc). Each one 401s, each calls `window.location.replace`, and each throws `AuthorizationError`. Those throws propagate to UI components that catch them and show "failed to get …" toasts before the navigation completes.

Fix

Add an `isReauthenticating` flag on `ApiClient`. First 401 in SSO mode triggers the reload AND sets the flag; subsequent in-flight 401s stall on a never-resolving promise instead of throwing.

```ts
if (!this.isReauthenticating) {
this.isReauthenticating = true;
window.location.replace(window.location.href);
}
return new Promise(() => {
// Intentionally never resolves — the page is navigating away.
});
```

The page IS navigating away, so blocking the caller forever is correct — there's nothing useful for the SPA to do with the result of a request that's about to be discarded. Subsequent throws would only generate noise.

Risk

Tiny. The change is scoped to the SSO + 401 branch of `ApiClient.fetch`:

• Non-SSO 401 path: unchanged (still calls `stores.auth.logout` and throws)
• Share-link path: unchanged
• Any non-401 status: unchanged
• Tests: no test currently exercises this branch (no jest spec for `ApiClient.ts` in the suite)

A never-resolving promise from `fetch` is the same shape callers see during a real network stall. Any caller that doesn't gracefully handle indefinite pending promises was already broken under normal network conditions.

Companion to

#19 (server-side stale-session flush). That PR makes the backend correctly clear the cookie on identity mismatch; this PR makes the user-visible reload smooth instead of flashing an error.

Test plan

• Manual: reproduce the original symptom (Logout-all → log in as different user → switch to Outline) on the dev stack. Expected: page reloads with new user's content, no error toast.
• Verify the non-SSO 401 path still logs the user out (set `AUTH_TYPE` to a non-SSO value locally, force a 401, expect `stores.auth.logout` to fire).

🤖 Generated with Claude Code