Persona respond-to edits never reach the running agent: card shows anyone, harness starts owner-only

### Summary

Editing an agent's respond-to setting on its persona card updates the persona and leaves the running agent on its old gate, permanently. The card shows one mode, the harness enforces another, and no amount of saving or restarting reconciles them.

We hit this across two Macs: an agent whose card read `anyone` (later `allowlist` with four keys) started with `respond_to=owner-only` on all six of its `buzz-acp starting:` lines, including after a full quit and reopen of Buzz Desktop. Every mention from a non-owner was dropped at `author_allowed` while the agent was online and healthy, and answering its owner normally.

Desktop 0.5.3, reproduced against upstream `b1b283c`.

### Root cause

`personaManagedAgentUpdate` (`desktop/src/features/profile/ui/UserProfilePanelUtils.ts:262`) is the function that pushes a persona edit down onto the linked managed-agent instance. It propagates `displayName`, `systemPrompt`, `model`, `envVars` and runtime-derived commands. It does not propagate `respondTo` or `respondToAllowlist`, even though `UpdateManagedAgentRequest` accepts both (`desktop/src-tauri/src/managed_agents/types/requests.rs:251`).

The write path for the persona side is `apply_persona_behavior` (`requests.rs:40`), which by design touches definition fields only. The instance side is populated by `resolve_mint_behavioral_defaults` (`types.rs:931`), which reads the definition's `respond_to` at **mint time only**. There is no later reconcile: `respond_to` appears zero times in `reconcile.rs`.

The spawn env is built from the instance record:

```rust
// desktop/src-tauri/src/managed_agents/runtime.rs, build_respond_to_env
set.push(("BUZZ_ACP_RESPOND_TO", record.respond_to.as_str().to_string()));
```

`ManagedAgentRecord::respond_to` is `#[serde(default)]` and `RespondTo`'s `#[default]` is `OwnerOnly`, so an instance row where the field was never written also deserializes silently to the most restrictive mode.

Observed on disk, `~/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json`:

| row | `respond_to` | `definition_respond_to` |
|---|---|---|
| definition row (no pubkey) | `owner-only` | `allowlist` (4 keys, correct) |
| instance row (agent pubkey) | `owner-only`, empty allowlist | absent |

### Why it took three days to find

The drop is invisible at the default log level. `inbound author gate — dropping event` is `tracing::debug!` (`crates/buzz-acp/src/lib.rs`) while the harness logs at INFO. A correctly delivered and correctly dropped mention leaves zero trace, so it is indistinguishable from an event that never arrived. We chased relay delivery, mention p-tags, the Desktop mention picker and `is_dm_channel` fail-closed behaviour before reading the agent's own startup line, which is the only place the effective gate is stated.

### Reproduce

1. Create an agent from a persona while the persona's respond-to is `owner-only`.
2. Edit the persona card's respond-to to `anyone` (or `allowlist`) and save.
3. Restart the agent, or fully quit and reopen Buzz Desktop.
4. Read the newest `buzz-acp starting:` line in `~/Library/Application Support/xyz.block.buzz.app/agents/logs/__.log`.

Expected: `respond_to=anyone`. Actual: `respond_to=owner-only`, indefinitely.

### Fix

PR attached: propagate `respondTo` / `respondToAllowlist` in `personaManagedAgentUpdate`, mode and allowlist together, treating a null persona `respondTo` as unset.

Two adjacent things worth considering separately:

1. **`useAgentManagement.ts:48` hardcodes `respondToAllowlist: []`** when relaying an inbound agent-management `update` request, so a `buzz agents draft-update --respond-to allowlist` can only ever fail the backend's non-empty-allowlist validation.
2. **Log the resolved gate at INFO on spawn and surface it on the card** ("running as: owner-only" next to the configured value). A security gate whose UI cannot be trusted to describe the process, and whose drops are invisible at the default log level, is expensive to diagnose. Promoting the drop line to INFO, or adding a periodic dropped-author count, would have made this a five-minute bug.

### Workaround

Until the fix lands, the only reliable local remedy is editing the instance row's `respond_to` in `managed-agents.json` with Buzz Desktop fully quit, then reopening. Verify by the next `buzz-acp starting:` line; the card is not evidence.

Start at personaManagedAgentUpdate in desktop/src/features/profile/ui/UserProfilePanelUtils.ts and compare its request fields with UpdateManagedAgentRequest in desktop/src-tauri/src/managed_agents/types/requests.rs. Trace resolve_mint_behavioral_defaults in types.rs and build_respond_to_env in runtime.rs, then reproduce using the documented persona edit and startup log; done means the newest starting line reflects the saved mode and allowlist after restart.

Written by the indexing model from the issue text.