fix(desktop): sync persona respond-to edits onto the linked agent instance

[xoxoskeleton]

Fixes #4487.

Problem

Editing an agent's respond-to on its persona card writes the persona and leaves the running agent on its old gate, permanently.

personaManagedAgentUpdate is the function that pushes a persona edit down onto the linked managed-agent instance. It propagates displayName, systemPrompt, model, envVars and the runtime-derived commands. It does not propagate respondTo / respondToAllowlist, even though UpdateManagedAgentRequest accepts both.

The harness spawn env is built from the instance record (build_respond_to_env), and resolve_mint_behavioral_defaults reads the definition at mint time only. Nothing reconciles the two afterwards, so an agent minted as owner-only stays owner-only for good: the card renders the persona's mode while every buzz-acp starting: line prints the stale instance value, and a restart re-reads that same stale value.

The failure is silent on both sides. The card asserts a gate the process does not enforce, and the drop itself (inbound author gate) is tracing::debug! while the harness logs at INFO, so a correctly delivered and correctly dropped mention leaves no trace at the default log level. It looks exactly like an event that never arrived. That cost us three days and four wrong theories before we read the agent's own startup line.

Change

One block in personaManagedAgentUpdate. Mode and allowlist travel together, matching the backend contract where a present allowlist replaces the stored one and allowlist mode with an empty list is rejected. A null persona respondTo means unset and leaves the instance alone, so personas that never authored a behavior group are unaffected.

Tests

Three new cases in UserProfilePanelUtils.test.mjs: mode change propagates, allowlist change propagates, and unchanged-or-unset produces no update. The persona fixture gains respondTo / respondToAllowlist so it matches the AgentPersona type it stands in for.

pnpm test in desktop/: 3888 pass, 0 fail. biome check and tsc --noEmit clean on the touched files.

Not in scope

Two adjacent issues found while tracing this, left out deliberately and described in #4487:

• useAgentManagement.ts:48 hardcodes respondToAllowlist: [] when relaying an inbound agent-management update, so allowlist mode over that path can only fail validation.
• The resolved gate is not logged at INFO on spawn and is not surfaced on the card, which is what made this expensive rather than trivial to diagnose.

[Chessing234]

nice — syncing persona respond-to onto the instance matches how build_respond_to_env actually reads the harness. tests cover mode + allowlist.

[wolfyy970]

This fixes a real mismatch, but I don’t think saving a persona should silently rewrite the linked agent. #4620 now documents the same definition/instance split.

The UI needs an explicit choice: edit this agent, or edit its template. An instance edit should target the keyed record immediately. A template edit should show the affected agents and require an explicit update. That keeps the card honest without turning every template save into an unreviewed rollout.

I have this flow running locally and described the wider boundary in #4301. Could this PR route an instance-card access edit to the keyed record instead of making persona edits propagate automatically?