Managed-agent UI updates visible persona record but runtime launches stale identity-backed duplicate

## Summary

Buzz Desktop can persist two records for one logical managed agent: a visible persona record with no agent pubkey and a hidden identity-backed record with the agent pubkey. Editing access settings in the only agent card shown by the UI updates the visible record, but the runtime continues to launch from the stale identity-backed record.

This makes the UI report `Only me` while the effective process still runs an old allowlist. A Desktop reboot preserves the split. It can also leave the agent stopped after reboot when the hidden identity-backed record has `start_on_app_launch=false`.

## Environment

- Buzz Desktop: `0.5.3`
- macOS
- Managed local Codex agents using `buzz-acp`

## Steps to reproduce

1. Have a managed agent whose persisted state contains both:
- a persona record with `pubkey: ""`; and
- an identity-backed record with the agent's public key.
2. In Desktop, open the only visible card for that logical agent.
3. Set **Who can talk to this agent** to **Only me** and save.
4. Inspect the persisted records and the next `buzz-acp starting` log line.
5. Reboot Desktop and inspect the records/processes again.

## Actual behavior

For Kerouac, the save produced this sequence:

- `20:54:08Z`: the visible non-identity record was updated to `respond_to: "owner-only"`.
- `20:54:12Z`: Desktop updated/restarted the hidden identity-backed record, but it remained `respond_to: "allowlist"` with one allowed public key.
- The runtime launch line at `20:54:12Z` reported `respond_to=allowlist(1)`.

Sanitized persisted state:

```json
[
{
"name": "Kerouac",
"pubkey": "",
"respond_to": "owner-only",
"respond_to_allowlist": [],
"start_on_app_launch": false,
"updated_at": "2026-08-03T20:54:08.508674+00:00"
},
{
"name": "Kerouac",
"pubkey": "eb586b1e…",
"respond_to": "allowlist",
"respond_to_allowlist": ["0a8e0720…"],
"start_on_app_launch": false,
"last_started_at": "2026-08-03T20:54:12.316207+00:00",
"updated_at": "2026-08-03T21:05:53.048151+00:00"
}
]
```

After reboot at approximately `21:06Z`:

- My Dude restarted with effective `owner-only`.
- waggle restarted with effective `owner-only`.
- Neil restarted with the stale effective `allowlist(3)`, despite the visible record having been reset to `owner-only`.
- Dennis did not restart; its hidden identity-backed record remained `allowlist(1)` and `start_on_app_launch=false`.
- Kerouac did not restart; its hidden identity-backed record remained `allowlist(1)` and `start_on_app_launch=false`.
- The process table contained exactly three `buzz-acp` processes, matching My Dude, waggle, and Neil.

The mismatch is user-visible operationally: a message accepted by three sibling agents was rejected before wake/model dispatch for Kerouac because its effective hidden record still excluded the sender.

## Expected behavior

- One canonical persisted record should represent each logical identity-backed managed agent.
- Changes made in the visible Desktop card should update the record used to launch the runtime.
- Access-policy and start-on-launch settings shown in the UI should match effective runtime settings after save and reboot.
- If legacy duplicate records exist, Desktop should reconcile/migrate them deterministically rather than continuing to launch stale configuration.

## Additional notes

- Repeated UI saves and a full Desktop reboot did not repair the state.
- No configuration files were hand-edited.
- No Buzz core changes or local patches were installed.
- Auth tags and private material are intentionally omitted.