Managed built-in agent allowlist UI diverges from persisted runtime allowlist

### Summary

Editing a managed built-in agent's **Who can talk to this agent → Allowlist** can show the newly selected identities in the Desktop UI while the effective persisted/runtime allowlist contains a different stale identity. Messages from the identity visibly selected in the UI are then silently ignored and do not wake the agent.

### Environment

- Buzz Desktop `v0.4.26`
- macOS
- Self-hosted relay
- Managed built-in agent (`builtin:bumble`)
- Codex harness

### Reproduction

1. Open a managed built-in agent and expand **Advanced**.
2. Set **Who can talk to this agent** to **Allowlist**.
3. Select an external bot/agent identity in **Search people**.
4. Save the changes and restart the agent/Desktop.
5. Have that identity publish a kind-9 channel message containing the managed agent's correct `p` tag.
6. Observe that the message reaches the relay/channel but does not start an agent turn.

### Expected

The identities displayed in the saved allowlist are persisted to the managed-agent record, passed to `buzz-acp`, and allowed to wake the agent.

### Actual

The UI showed two selected identities, including the external sender, but the persisted managed-agent record contained only one different/stale identity:

```text
respond_to=allowlist(1)
```

The external sender's pubkey was absent from the effective allowlist. Its correctly tagged kind-9 messages appeared in the channel but created no agent activity/turn. A subsequent mention from the human owner did wake the agent, which could then read the earlier messages.

Outbound replies and relay storage worked normally. This isolates the failure to allowlist persistence/reconciliation or the inbound author gate, not relay delivery.

### Additional observations

- The external sender used the managed agent's exact public key in the Nostr `p` tag.
- The managed agent could find the messages through channel-history tools after a human-authored event started a turn.
- Current source appears intended to submit and persist `respond_to_allowlist`, so this may involve reconciliation between a built-in linked definition, its managed instance, and the edit dialog/runtime snapshot.
- This is distinct from forum-post mention routing: the reproducer uses kind 9.

### Security impact

The obvious workaround is setting the agent to **Anyone**, but that unnecessarily broadens who can invoke an operationally capable agent. A reliable explicit allowlist is important for infrastructure and automation bots.