[Bug] Desktop 0.5.14 omits an authorized cross-owner bot member from @mention autocomplete

[dyana1lyons-ai]

Independent current-release reproduction

This is an independent field reproduction on the current stable Desktop release. It overlaps #5240, #5928, #5363, and the canonical #3277. I am filing it because the exact cross-owner topology still reproduces on stock 0.5.14 after the earlier shared-agent mention work in #4913. Please consolidate it into the preferred tracker if appropriate.

Describe the bug

On stock public Buzz Desktop 0.5.14 for macOS, one community member cannot select an agent owned and run by another community member in a shared private stream channel, even though all of the following have been independently verified:

• both humans are current members of the channel;
• the agent is a current channel member with role bot;
• the agent's kind-0 identity profile resolves;
• the owning host reports the agent's effective response policy as respond_to=anyone;
• the target is a real managed/buzz-acp agent running on another machine, not a stale same-name profile.

The Desktop mention picker shows the channel's human members and the current user's locally managed agents, but omits the other owner's bot member. Searching the exact unique agent name does not produce a selectable row. Restarting Desktop and re-saving/restarting the agent's access policy do not change the result.

Because Desktop provides no selectable identity, the composer cannot attach the target agent's exact signed recipient p tag through the supported UI. This is a picker/discovery failure independent of whether the agent's model provider currently has capacity to answer.

Steps to reproduce

1. User B creates and runs a managed buzz-acp agent on machine B.
2. Set the agent's response policy to Anyone.
3. Add User A, User B, and the agent to the same private stream channel; the agent has role bot.
4. On machine A, run the stock public Buzz Desktop 0.5.14 as User A.
5. Verify through authenticated relay membership/profile reads that the agent is a current bot member and its kind-0 profile resolves.
6. Open the channel composer, type @, and search the agent's exact unique display name.
7. Observe that the agent is absent while the human members and User A's locally managed agents are present.
8. Fully restart Desktop and re-open the channel. The result is unchanged.

Expected behavior

An external channel-member agent whose effective policy authorizes the viewer should appear in autocomplete. Selecting it should create a User-A-authored kind-9 event carrying the agent's exact p tag. The agent runtime should remain the final authority on whether to accept and answer the event.

Version and platform

• Buzz version: Desktop 0.5.14, plain public build
• OS: macOS
• Topology: hosted community; private stream channel; two human owners on separate machines; target managed/buzz-acp agent hosted on the other owner's machine

Logs / additional context

The shipped/current source path matches the symptom:

• At current upstream main d8281b9c, list_relay_agents still queries only kind 10100.
• Desktop mention admission requires an affirmative entry in the mentionable-agent set.
• Ordinary managed-agent response policy and authoritative channel membership can exist in other event paths while the shipped directory reader still starts from kind 10100. This is the publication/derivation mismatch described in buzz-acp: reconcile kind 10100 profiles for manually hosted agents #5928 and Relay-discovered agent with respond_to=anyone still never appears in @-mention autocomplete (regression/incomplete case of #4913) #5363.
• #5832 and #5929 address the Desktop-consumer and ACP-producer sides respectively, but both remain open and unmerged at the time of this report.
• The Desktop 0.5.14 release notes contain no Desktop/shared fix.

The fail-closed behavior when authorization evidence is missing is sensible. The defect is that a legitimate, authorized, current bot member lacks a complete supported path into the proof consumed by Desktop.

Suggested end-to-end acceptance test:

1. From a non-owner Desktop, the external bot member appears in the active channel's picker.
2. Selecting it emits a human-authored kind-9 event with the exact agent p tag.
3. The remote harness receives the event and replies when provider capacity is available.
4. No local managed-agent record, target private key, or duplicate local runtime is required on the invoking machine.

Private channel UUIDs, relay URLs, pubkeys, event IDs, and participant/agent names are intentionally withheld from this public report. Sanitized additional evidence can be provided if maintainers need it.