Editing an existing agent's "Respond to" never reaches the running instance (UI and runtime disagree, no error)

### Setup

- Two machines, same owner identity, same hosted relay: Windows 11 and macOS, both on `desktop-v0.5.11` (latest at time of filing).
- The agent runs only on the Windows machine: local backend, ACP harness.
- The affected agent is linked to a built-in persona definition. A second agent, linked to a user-created definition, is unaffected (see "Contrast" below).

### Steps to reproduce

1. On machine A, create an agent from a persona definition and leave "Respond to" at the default (Owner only). Start it.
2. Open the agent's settings and change "Respond to" to Anyone. Save. The UI now shows Anyone.
3. Restart the agent.
4. On machine B, signed in as the same owner, open a channel the agent belongs to and start a mention in the composer.

**Expected:** the agent is offered in autocomplete, and it answers anyone.

**Actual:** the agent is absent from autocomplete on machine B, and the harness still enforces `owner-only`. No error is shown anywhere.

### Observed state for one agent, after the edit

| Where | `respond_to` |
|---|---|
| Settings UI on machine A | Anyone |
| Published `kind:30175` definition | `anyone` |
| Published `kind:30177` instance | `owner-only` |
| `managed-agents.json` instance record | `owner-only` |
| Running harness environment | `BUZZ_ACP_RESPOND_TO=owner-only` |

The definition was updated. Everything that actually decides behaviour was not.

### Contrast

A second agent, created directly with "selected people", carries `allowlist` in both its published `kind:30177` and its local instance record, and it behaves correctly. So the create path writes the instance field, and only a later edit diverges.

That matches the code: `update_managed_agent` (`desktop/src-tauri/src/commands/agent_models.rs:706`) writes `record.respond_to`, while `update_persona` writes the definition and never touches linked instances. `definition_respond_to` is populated only by the snapshot-import and team-import paths. Per NIP-AP, `respond_to` is an instance-level field on `kind:30177`, so a definition edit cannot reach the running agent.

### Why it hurts more than it looks

`relayAgentIsSharedWithUser` in `desktop/src/features/agents/lib/agentAutocompleteEligibility.ts` admits an agent to mention autocomplete only when `respond_to` is `anyone`, or `allowlist` containing the viewer. It never checks ownership. An agent stuck at `owner-only` is therefore unmentionable from every device that does not hold its key, including the owner's own second machine, while its settings page insists it answers anyone. Messages to it are silently not delivered, and the owner has no way to see the split from the UI.

### Underlying expectation

When you create an agent on one machine, you expect to talk to *that* agent from anywhere: your other laptop, your phone, the web. Not to a local stand-in that happens to share its name. Today the second machine silently offers a fresh, unconfigured copy instead, and nothing in the UI says which one you are about to message. Whatever the mechanism ends up being, the agent you created should be the agent you reach. Related: #5794.

### Expected fix

A respond-to edit propagates to linked instances (with a restart prompt), or the persona dialog stops presenting an instance-level field as a definition-level one. Related: #5705, which is the same shape for the display name.

Start with update_persona and update_managed_agent in desktop/src-tauri/src/commands/agent_models.rs, then inspect relayAgentIsSharedWithUser in desktop/src/features/agents/lib/agentAutocompleteEligibility.ts. Trace how edits reach the published kind:30177 instance, managed-agents.json, and the running harness. Done means a Respond to edit keeps those values aligned and the UI handles the required restart prompt.

Written by the indexing model from the issue text.