[Bug] Desktop 0.5.2 re-runs onboarding on every launch on a second machine — new Welcome channel + duplicate Honey each time

**Describe the bug**

On a second machine signed into an existing community, Buzz Desktop re-runs first-time onboarding on **every app launch**, not just on first install. Each launch creates another "Welcome" channel and mints another copy of the default starter agent (Honey) with a fresh Nostr keypair.

This looks related to #2648 (second install mints the default roster once) but is a distinct, more aggressive variant: the re-mint happens **per launch on a single install**, and on v0.5.2, which already includes the duplicate-minting guard from #3221.

**Steps to reproduce**

1. Machine A (Mac mini): create a hosted community (`*.communities.buzz.xyz`) with Buzz Desktop; delete the default starter agent (Honey) from the community.
2. Machine B (MacBook): install Buzz Desktop v0.5.2 in `/Applications` (installed from the DMG correctly — not running from the mounted image), and sign in with the **same existing identity** into the **same community**.
3. Observe: a new "Welcome" channel appears and a new "Honey" agent (fresh pubkey, same display name/avatar) is created.
4. Quit Buzz Desktop and relaunch. Another Welcome channel and another Honey are created. This repeats on every launch.

**Expected behavior**

Onboarding/bootstrap should run at most once per install — ideally not at all when the identity already owns channels in the community. Relaunching the app should never mint new starter channels or agent identities.

**Version and platform**

- Buzz version: 0.5.2 (machine B, where the re-mint happens)
- OS: macOS (both machines)

**Logs / additional context**

Relay-side evidence, gathered with the CLI against the community relay: `buzz users get --name Honey` returns **4 distinct profiles**, identical display name and avatar, different pubkeys (first 8: `6f780449`, `13d7678b`, `ef1c2dc4`, `de94ed7a`) — one per onboarding run. The original channels and the owner's membership are intact throughout; only the starter content is duplicated.

Possibly relevant detail: the community's original default Honey agent had been **deleted** on machine A before machine B ever signed in. If the launch-time bootstrap checks "does the default roster exist?" and recreates it when missing, that would explain both the recreation of a deleted agent and the per-launch loop (machine B's freshly minted Honeys live only in machine B's local state, so a check against synced/local state could keep failing).

The duplicate identities appear inert (their private keys exist only on machine B), matching the "dead on arrival" duplicates described in #2648.