Managed-agent instance config (kind:30177) never syncs cross-device, causing every member device to auto-offer a duplicate/unconfigured local agent

## Summary

When a persona (e.g. an agent named "Fizz") is created and properly configured on one device (Owner's host — provider/model/harness set, e.g. Codex), **every other device that simply joins the same channel/community independently offers to run its own separate local instance of that same persona**, defaulting to "needs setup on this device." If that device has any agent runtime enabled (e.g. the `Buzz Agent` runtime, which cannot be toggled off in the UI), it auto-spawns a local `buzz-acp` process in a setup-mode listener state — which then sends spurious "Fizz needs configuration" replies into the channel, competing with the properly-configured instance on the intended host machine.

This defeats the "one shared team agent" use case entirely — every team member's device ends up needing its own separate, fully-duplicated configuration (including a separate provider login, e.g. a separate `codex login`/ChatGPT session per device) just to avoid broken replies, even though only one device is meant to actually host the agent.

## Root cause (traced in source)

Two relay sync paths are asymmetric:

- **Persona definition** (kind:30175) — propagates to every member device unconditionally. `apply_inbound_persona` (`desktop/src-tauri/src/commands/personas/inbound.rs`, ~line 342-364) inserts the persona locally on any device that receives the event, regardless of `BackendKind`.
- **Managed agent instance record** (kind:30177) — carries the actual `backend` field (`BackendKind::Local` vs `BackendKind::Provider{id, config}`) and is the thing that would tell another device "this persona is already actively hosted elsewhere." `apply_inbound_managed_agent` (same file, ~line 376-405) is an explicit no-op when there's no local match, per the existing comment: *"an agent that does not already exist locally has no secret key to run with, so inserting a secretless shell would be useless and misleading."*

Because only the definition (kind:30175) propagates and never the instance/backend state (kind:30177), every device that receives the persona has no way to know it's already hosted elsewhere. `ManagedAgentRuntimeStatus.localSetup` (`desktop/src/shared/api/types.ts`) and `agentCommunityAvailability()` (`desktop/src/features/agents/managedAgentRuntimeStatus.ts`, ~line 9-25) compute "needs setup on this device" purely from local state — there's no cross-device ownership/exclusivity check anywhere in `reconcile.rs`, `discovery.rs`, or `persona_events.rs`.

Notably, the recently-shipped "explain open agent access" work (#2561) reframes `respond-to` for a **provider-backed (remote) agent** — "Anyone can use this agent to access the server it runs on" — which reads as if it already solves centralized/shared hosting. It doesn't: that wording only describes where the *owner's own* instance computes (local machine vs. a `buzz-backend-*` remote provider). It has no effect on whether *other* member devices independently offer/spawn their own separate instance of the same persona — because, per the above, `BackendKind`/instance state never syncs to them in the first place.

## Steps to reproduce

1. Device A (owner): create a persona ("Fizz"), configure it fully (harness = Codex, model = gpt-5-codex, logged in), set `respond_to: Anyone`. Confirm it replies correctly to `@Fizz` messages.
2. Device B (a different machine, logged in as a different community member, or even the same identity paired to a second device): join the same channel that "Fizz" is a member of. Do not touch Agents/Compute settings on Device B at all.
3. Observe: Device B's Agents/Compute page lists "Fizz — NEEDS SETUP ON THIS DEVICE" despite never having been asked to host it.
4. If Device B has any agent runtime enabled (`Buzz Agent` toggle — could not find a way to disable this in the UI), a `buzz-acp` process spawns locally in setup-mode and independently replies to `@Fizz` mentions in the shared channel with "Fizz needs configuration — set the provider field / set the model field," even though Device A's instance is fully configured and already replying correctly. Both replies land in the same thread, and which one wins is a race.

## Expected behavior

A persona that already has an actively-hosted managed instance elsewhere (owner-configured, `respond_to` set to share access) should not cause other member devices to auto-offer/auto-spawn their own competing local instance. At minimum, the setup-mode listener should not fire (or should not post visible "needs configuration" replies into shared channels) on devices that are not the persona's designated host.

## Impact

This is the core blocker for using Buzz as a "one shared team agent, everyone just talks to it" tool (the natural Discord-bot-style expectation) — currently every team member's machine needs its own fully separate agent configuration (including separate provider credentials/login) to avoid broken/competing replies, which does not scale to a team and contradicts the stated design intent behind #2561's "provider-backed (remote) agent" access model.

## Environment

- Buzz Desktop, self-hosted relay deployment (on-prem Rust relay, own Postgres/Redis/MinIO)
- Reproduced on `main` at commit 4672ee5 (post-#2561)
- macOS and Windows desktop clients