Provider-backed managed agents have no management surface on the owner's other desktops — sync agent records across devices

**Motivation**

Anyone who runs Buzz Desktop on more than one machine and uses a `buzz-backend-*` provider hits this. I self-host a relay and deploy agents to an always-on cloud VM through a custom provider plugin. The agents themselves are healthy from every device — they live on the VM and in relay channels. But the *management* of those agents is pinned to the single desktop that created them: managed-agent records (including `backend`/`backend_agent_id`/`provider_config`) live only in that machine's local app data, and `agent_snapshot.rs` deliberately excludes backend fields from what's published to the relay. On every other desktop I own there is no card, no deploy/shutdown, no model info — and if the originating machine's local record is lost, a healthy remote deployment is permanently orphaned (no `undeploy` in the v1 provider protocol, per the deferral note in `commands/agents.rs`). The durable-agent benefit of remote backends inverts: the agent outlives any laptop, but its controls don't.

**Proposed solution**

Owner-scoped sync of managed-agent records through the relay, so the same owner signed in on another desktop can see and manage their provider-backed agents:

- A NIP-44 owner-encrypted record event carrying the non-secret management fields (provider id, `backend_agent_id`, `provider_config`, runtime/model), with key material either included under owner encryption or explicitly re-paired per device.
- When a synced record references provider `X` and `buzz-backend-X` isn't installed locally, degrade gracefully: show the card read-only with a hint ("managed via provider X — install `buzz-backend-X` to manage from here") instead of showing nothing.

**Alternatives considered**

- *Install the plugin on every machine*: doesn't help — the records still don't sync, so other desktops can't see the agents to manage them.
- *Designate one "admin" machine*: workable discipline, but fragile (single point of failure for management) and surprising to users who expect account-level state.
- *Manage out-of-band over SSH*: what I do today; works, but bypasses the UI the feature exists to provide.

**Additional context**

- Related but distinct open issues about *mention/discovery* of agents on secondary devices: #2349 (closest), #3277, #4187. This issue is about the management/records layer for provider-backed agents rather than mentionability.
- Provider protocol reference points: `desktop/src-tauri/src/managed_agents/backend.rs` (discovery, `invoke_provider`), `agent_snapshot.rs` (backend fields excluded from relay), `commands/agents.rs` (undeploy deferred to v2).
- Happy to test any proposed record-sync approach against a real self-hosted deployment (Railway relay + DigitalOcean agent host + custom provider plugin).

Start by reading desktop/src-tauri/src/managed_agents/backend.rs, agent_snapshot.rs, and commands/agents.rs to understand provider discovery, relay publication, and the undeploy limitation. Then trace the existing relay and owner-encryption paths before choosing a record-sync design. Done means provider-backed managed-agent records are available to the same owner on another desktop, with a read-only fallback when the provider is missing.

Written by the indexing model from the issue text.