fix(desktop): fence localStorage SecurityError from killing the React tree

[iroiro147]

Summary

WebKit throws SecurityError from localStorage.getItem (not just setItem) when storage access is denied for the origin. With no ErrorBoundary in desktop/src, any such throw inside a provider render (ThemeProvider, CommunitiesProvider, App boot) propagated to the reconciler, unmounted the root, and left a blank window. Measured repro in #5078: a single throwing getItem on buzz-communities or buzz-active-community-id kills the container.

Closes #5078.

What changed

New helper — desktop/src/shared/lib/safeStorage.ts

• getStorageItem(key, fallback?) — wraps window.localStorage.getItem; on a thrown error (SecurityError under denied-storage origin) it warns once per key and returns the fallback.
• setStorageItem(key, value) and removeStorageItem(key) — same fail-closed contract (return false on throw).
• Unit tests in safeStorage.test.mjs cover the happy path and the SecurityError path.

Rewired the init-path readers that ran before any UI existed

• desktop/src/features/communities/communityStorage.ts — migrateLegacyCommunityStorage, loadCommunities, loadActiveCommunityId, loadCommunityDiscoveryAfterLeave, initFirstCommunity
• desktop/src/features/communities/legacyCommunityStorage.ts — migrateLegacyCommunityStorageBeforeRender
• desktop/src/shared/theme/ThemeProvider.tsx — readStoredTheme, applyCachedVars, the useState initialisers for accentColor and followSystem, and the accent re-read inside applyTheme

Root-level fence — desktop/src/app/RootErrorBoundary.tsx

• New top-level ErrorBoundary wrapping the whole provider tree in main.tsx. Any remaining uncaught render error (a future storage read that bypasses the helper, or any other render-time crash) renders a degraded splash with a Reload button instead of a blank window.

Test plan

• desktop/src/shared/lib/safeStorage.test.mjs — node --test runner, 11 assertions across healthy, absent, and SecurityError-throwing storage.
• Full just ci runs on the blocker.
• Existing communityStorage.test.mjs and legacyCommunityStorage.test.mjs continue to pass (they exercise the same functions via in-memory Storage doubles; the new code path in migrateLegacyCommunityStorage only adds a try/catch around the same body).

Why not an ErrorBoundary-only fix

A boundary alone can't help on a clean mount — the first throw already unmounted the whole subtree before any state or fallback data was loaded, so retrying would hit the same throw on the very next render. The storage accessor has to fail closed and the boundary has to exist for whatever bypasses it. Both are needed; neither is sufficient alone.

[wesbillman]

Carl reviewing on behalf of Wes at exact head 4d832212147d44c3b77cddf4b15333ae1261f4d6 as a release/security gate.

The production approach is directionally sound: the diff is confined to the seven advertised desktop files; I found no dependency, workflow, native-command, network, credential, or code-loading changes; the guarded startup reads preserve healthy-storage values and fail closed under denied storage. I am requesting changes before release for the following blockers:

1. The newly added tests do not run in the repository's actual test environment. pnpm test fails all six safeStorage.test.mjs cases with ReferenceError: window is not defined at patchLocalStorage (safeStorage.test.mjs:31). Result: 4480 pass / 6 fail. These tests need to install/restore a globalThis.window (using the repo's established DOM-test pattern) rather than assuming the Node runner supplies one.

2. The acceptance behavior is not tested end to end. The helper tests—even once repaired—only call three wrappers directly. They do not prove that a denied localStorage.getItem during CommunitiesProvider/ThemeProvider initialization leaves a visible tree, nor that the root boundary renders a recoverable surface for a remaining render-time throw. Please add a deterministic mounted regression that injects a throwing storage implementation before mount and asserts a non-empty, actionable fallback/default UI. This is the core release guarantee, not decorative shrubbery.

3. The root fallback renders arbitrary error.message text to the user (RootErrorBoundary.tsx:40-42). Because this boundary catches every render error, those messages can contain internal paths, request details, identifiers, or other diagnostic data. Keep the UI generic and log the diagnostic only via componentDidCatch.

Additionally, pnpm check reports a formatter error introduced in main.tsx:84-99; the other reported lint items pre-exist outside this diff. pnpm typecheck and git diff --check pass.

I also traced bootstrap before the boundary: the production storage paths currently invoked there (recoverLocalStorageQuotaOnStartup and legacy migration/application) are locally caught, so I did not find a separate pre-boundary production escape in this diff. Fix the failing tests, prove the actual mounted denial/fallback behavior, avoid exposing raw errors, and format the file; then this should be straightforward to reassess.