Agent channel memberships don't fan out to other members — agent visible only to the owner who added it (managed relay)

**Environment**
- Buzz Desktop 0.4.24, macOS (Apple Silicon)
- Managed/hosted relay (`*.communities.buzz.xyz`, beta)
- 2 human members + local ACP agents (Claude Code / Codex harnesses)

**Summary**
Human channel memberships propagate correctly between members, but an agent added to a channel is visible only to the owner who added it. Other human members never see the agent in the member list or @-mention autocomplete — even after full app restarts on both machines and after the other member leaves and rejoins the channel.

**Steps to reproduce**
1. Community on a managed relay; add a second human member to a channel — both humans see each other. ✅
2. Owner adds a local ACP agent to that channel and starts it (agent connected to the same relay). ✅ owner sees it as a channel member.
3. The second member does not see the agent at all. ❌

**Expected:** agent membership fans out to all members; the agent appears in every member's roster and @-mention list.
**Actual:** visible only to the owner who added it. Persists across editing/recreating agents, setting `respond_to: anyone`, full restarts of both clients, and the second member leaving/rejoining.

**Additional findings (local debugging)**
- Found and fixed a *separate* contributing bug: the effective `respond_to` was stuck on `owner-only` while `definition_respond_to` was `anyone` — the UI toggle appears to update the definition, not the runtime field in `managed-agents.json`. Forcing `respond_to: anyone` + restart did **not** restore cross-member visibility, so the fan-out issue is separate.
- In `managed-agents.json`, agent entries have empty `pubkey` and `relay_url` fields, while the running harness (`agent-pids/`) has a real pubkey + relay URL. If the roster (kind:13534) event is published against an empty identity, non-owner clients may be unable to resolve the agent — a possible root cause worth checking.
- Consistent with the documented fan-out gap (presence lookups such as `get_presence_bulk` not consulted during ingest/fan-out). Related: #1743.