Builderlab sign-in on Settings → Hosted communities does not survive an app restart

## Summary

Signing in with Builderlab under **Settings → Hosted communities** works, and the
connected state persists for the lifetime of the app process. But every time Buzz Desktop
is fully closed and reopened, that page is signed out again and shows the "Sign in to
manage hosted communities" prompt.

The Buzz identity itself is unaffected — the app reopens signed in, channels and agents
load normally. Only the Builderlab-authenticated page reverts.

## Environment

- Buzz Desktop 0.5.14 (Windows x64)
- Windows 11 Home, build 26200
- Hosted community on `*.communities.buzz.xyz`, one community of five used

## Steps to reproduce

1. Open Settings → Hosted communities and sign in with Builderlab. Authentication
completes in the browser and returns to the app.
2. Confirm the page shows the account, "Buzz identity connected", and the community list.
3. Fully quit Buzz Desktop (including the tray process) and relaunch it.
4. Return to Settings → Hosted communities.

**Expected:** still signed in, or an explicit statement that this page requires signing in
each session.

**Actual:** the page shows "Sign in to manage hosted communities" again. Signing in works
every time, so this is not a credential or token-rejection failure — the session simply
isn't there after restart.

## Likely mechanism

Inspecting the app's WebView2 profile (structure and modification times only, no values
read):

| Store | Entries | Last modified |
|-----------------|---------|----------------------------------|
| Local Storage | 1 | install date, untouched since |
| Session Storage | 6 | current, written during this run |

Session storage is discarded when the browsing context ends, which for a Tauri desktop
app is application exit. Local storage — the store that would survive — appears unused
since installation.

That points to the Builderlab session being held in session-scoped web storage rather
than persistent storage. The WebView2 profile itself is on disk and does persist, so
durable storage is available and simply isn't being used for this.

This is inferred from write timestamps rather than by reading the stored token, so treat
it as strong circumstantial evidence rather than confirmed.

## Question

Is this intended? The page states "Builderlab sign-in is used on this page alone", which
could describe a deliberately narrow, re-auth-per-session console. If so, that is
reasonable — but the page gives no indication of it, and simply reverting to a sign-in
prompt reads as a forgotten session rather than a policy.

Page-scoping and session-persistence are independent concerns: a token can be scoped to
one settings page and still be remembered across restarts.

## Suggested fix

Either:

1. Persist the Builderlab session in durable storage so it survives a restart, with a
normal expiry and a visible sign-out control; or
2. If per-session re-authentication is intentional, say so on the page so users do not
read it as a bug.