fix(desktop): persist agent respond-to edits to linked instances (#2501)

[DMcGee22]

Summary

Fixes #2501 — editing an agent's "Who can talk to this agent" (respond_to)
setting in Desktop never reaches the running agent, so custom agents silently
stay owner-only and no one but the owner can talk to them.

Root cause. A persona definition and the managed-agent instances linked
to it are separate records. The definition's respond-to gate is copied onto an
instance's respond_to at mint time only (see the field docs on
ManagedAgentRecord, managed_agents/types.rs). The harness (buzz-acp) spawns
from the instance field. update_persona already propagates display-name and
avatar edits to linked instances, but never propagated the respond-to gate — so
a post-mint edit updated definition_respond_to while the instance's
respond_to stayed stale, and the agent kept booting respond_to=owner-only.

Fix

• New propagate_persona_respond_to helper (in a new personas/propagate.rs,
  alongside the existing propagate_persona_name_rename): on a definition
  behavior edit, converge every linked instance's respond_to to the
  definition gate. The allowlist is replaced only in allowlist mode, so
  toggling away and back doesn't lose entries (matching the preserve-across-
  toggle semantics already documented on the field). Key-less definition rows
  are skipped.
• update_persona calls it whenever a behavior group is present.
• Extracting the helpers into propagate.rs keeps mod.rs under its size cap.

Scope is intentionally minimal: one module + wiring + unit tests, no unrelated
changes.

Relationship to #2505

#2505 also targets #2501 with an equivalent core, but bundles an unrelated DB
partition-overlap fix (#2474) and some extra churn, and has sat unreviewed. This
PR is the focused, single-purpose version — just the respond-to propagation and
its tests. Happy to defer to #2505 if maintainers prefer; closing #2501 either
way.

Test plan

• cargo test --manifest-path desktop/src-tauri/Cargo.toml --lib propagat
  — new respond_to_propagation_tests + existing name_propagation_tests
  pass.
• Unit coverage: anyone/allowlist propagate to linked instances only;
  non-allowlist mode preserves the stored instance allowlist; absent gate
  resolves to owner-only; no-op edits report zero changes; key-less rows are
  skipped; an invalid definition allowlist is rejected without mutating records.
• Manual (per [Bug] <Desktop: agent respond_to / allowlist edits don't persist — buzz-acp always starts with owner-only> #2501 repro): set a custom agent to Anyone, restart it, confirm
  the harness log shows respond_to=anyone; a non-owner member @mention now
  gets a response.

[chatgpt-codex-connector]

💡 Codex Review

buzz/desktop/src-tauri/src/commands/personas/mod.rs

Lines 262 to 263 in 1f80a1e

	if agents_modified {
	save_managed_agents(&app, &records)?;

Enqueue agent events after propagating access changes

When a persona's respond_to settings are changed for existing linked agents, this block persists the modified records but never calls retain_managed_agent_pending for them. Unlike the direct managed-agent update path, the corresponding kind:30177 events therefore retain their old respond_to and allowlist values until the next application boot runs disk-to-relay reconciliation; other clients continue using those stale events for mention eligibility, so an owner-only → anyone or allowlist edit does not become usable by the intended users while the app remains open. Enqueue an updated event for every propagated record after saving.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".