Joining a second community leaks the agent roster (kind:30177/30175) into it and runs starter onboarding there

## Summary

A single Desktop install that joins a **second** community publishes its entire local agent roster into that community and treats it as un-onboarded — seeding the starter channels and spawning the built-in greeters there. Nothing in the UI indicates either is happening, and undoing it requires relay-side surgery.

Two independent mechanisms:

1. **Boot-time roster reconcile is community-agnostic.** `desktop/src-tauri/src/managed_agents/reconcile.rs` reconciles every pubkey-carrying record in `managed-agents.json` into `kind:30177` events (and personas into `kind:30175`) and flushes them to whichever community the app is connected to. There is no notion of an agent's *home* community and no deletion reconcile, so agents built for community A get announced into community B on the first boot with B active — including long-disabled records and leftover built-in instances.
2. **First-visit onboarding runs in joined communities, not only created ones.** `desktop/src/features/onboarding/welcome.ts` ensures the starter channels (`Welcome`/`general`/`welcome-everyone`) and spawns Fizz/Honey/Bumble with fresh keypairs (the per-community minting rule described in #4255) in any community whose per-community localStorage flag is unset — a community the user *joined* qualifies. In our case the greeters posted their welcome into a private family community that was deliberately kept minimal.

## Environment

- Buzz Desktop **0.5.8**, macOS (Apple Silicon), single installation
- Self-hosted relay, two host-keyed communities on one container (`` and `:9444`), both owned by the same key

## To reproduce

1. Run a desktop install with managed agents in community A.
2. Join community B (same relay, different host) from the same install.
3. Restart the app with B active.
4. Inspect B's event store: one `kind:30177` per local agent record, `kind:30175` personas, starter channels created, greeter identities with fresh keypairs plus welcome messages.

## Observed here (from the relay DB)

- 8 × `kind:30177` (two live agents + six zombie built-in records left over from earlier onboardings) and 2 × `kind:30175` — full system prompts — published into the second community within one minute of a boot.
- Starter channels and three greeter identities created there; the `users` projection gained rows for community-A agents (empty display names).

## Impact

- Agent roster metadata (names, models, settings) becomes visible to members of an unrelated community. (`kind:30175` is correctly author-gated unless shared — good — but `30177` is not.)
- Zombie greeter identities accumulate per community (compounds #4255 / #2515).
- Cleanup means deleting relay events and archiving channels by hand.

## Expected

- Roster events scoped to an agent's home community — or an explicit share step, like the `shared`-tag model 30175 already has, applied to 30177.
- Starter onboarding only in communities the user creates/owns — or an explicit prompt before seeding channels and spawning agents in a joined one.

## Related

- #4255 — the built-in per-community keypair minting rule (this issue is about the roster sync + onboarding trigger, not the minting rule)
- #2515 — cross-community agent collision in channels (a downstream symptom of the same missing home-community scoping)