[Bug] <Desktop: agent respond_to / allowlist edits don't persist — buzz-acp always starts with owner-only>

## Summary

Editing an agent's **"Who can talk to this agent"** setting in the Desktop UI
(changing `respond_to` to *Anyone* or *Allowlist*, and adding a human pubkey to
the allowlist) does **not** persist to the value the `buzz-acp` harness actually
uses. The harness keeps starting with `respond_to=owner-only`, so non-owner
members can never interact with the agent, regardless of what the UI shows.

## Environment

- Buzz Desktop **v0.4.23** (macOS, Apple Silicon)
- Self-hosted relay: `ghcr.io/block/buzz:mainIRE_RELAY_MEMBERSHIP=true`)
- Agent: a **custom** agent (not a built-in Welcome Team persona), runtime `claude`

## Steps to reproduce

1. Create a custom agent (owner-only by default).
2. Open its config → **Who can talk to this ae**
(also tried **Allowlist** + add a member's pubkey). Save.
3. Restart the agent (also tried: stop → edit
4. Have a non-owner member @mention the agent in a shared channel.

## Expected

The agent responds to the member (Anyone), or to allowlisted members (Allowlist).

## Actual

- The member gets no response.
- The `buzz-acp starting` log line always sho.
- This reproduced identically on the hosted (Builderlab) relay too, so it is not
relay-specific.

## Evidence

In `~/Library/Application Support/xyz.block.bnts.json`,
after changing the UI to "Anyone", the agent's **definition** entry shows a
desync:

"respond_to": "owner-only", // v
"definition_respond_to": "anyone", // what the UI wrote ✅
"respond_to_allowlist": [] // sng a member ❌

So the UI writes `definition_respond_to`, butrom
`respond_to` (unchanged) and `respond_to_allowlist` (never populated). There are
effectively three out-of-sync states: **UI shig file
has `definition_respond_to` set but `respond_to` stale, and the **running
harness uses `owner-only`**.

Harness log:

buzz-acp starting: ... respond_to=owner-o

## Workaround (confirms the root cause)

Editing `managed-agents.json` **by hand** wit
`respond_to: "allowlist"` and adding the member pubkey to
`respond_to_allowlist` in the agent's entries reopening
the app the harness starts correctly:

buzz-acp starting: ... respond_to=allowlist(1)

The app did **not** revert the manual edit, so the config file is the source of
truth; the UI edit path is what fails to writ
`respond_to_allowlist`.

## Impact

Custom agents cannot be shared with other community members through the UI at
all — they silently stay owner-only. Only a manual file edit works.