fix(desktop): let channel-member agents be mentioned

[yjc801]

Summary

An agent owned by someone else could never be mentioned, even when its owner had explicitly allowlisted the mentioning user. Found while investigating why an agent that was a bot-role member of a channel, with permission granted, simply did not appear in the @ picker.

The mention picker ran two agent gates in sequence, and the first made the second's intent unreachable:

if (!isAgentIdentityInAllowedList(candidate, mentionableAgentPubkeys)) return;
if (shouldHideAgentFromMentions({ ... })) return;

isAgentIdentityInAllowedList rejects every candidate flagged isAgent that isn't already in mentionableAgentPubkeys. shouldHideAgentFromMentions is a strict superset of that check except for exactly one case, which it handles deliberately and documents at length:

// Member (Option B): hide only when we have an explicit not-invocable
// signal — a relay directory (kind:10100) entry that excludes us.
// Unknown invocability (not in directory) => show.

That branch never ran. The first gate dropped the candidate before it could apply.

Why the effect is total, not marginal. A relay agent enters mentionableAgentPubkeys only via channel_ids / respond_to / respond_to_allowlist, read from its kind:10100 profile. Nothing in this repo publishes that event. The only writer is buzz channels set-add-policy, whose content is just {"channel_add_policy": …} — and since kind 10100 is replaceable (asserted at compile time in buzz-core/src/kind.rs), that write also erases any profile that did exist. So the directory is empty in practice, no other-owner agent can enter the allowed set, and all of them were hidden.

The fix: gate on shouldHideAgentFromMentions alone.

Reviewer notes

• Nothing else loosens. Non-member agents are still hidden (if (!isMember) return true), and a directory entry that excludes the viewer still hides (return directoryAgentPubkeys.has(...)). The only behavior change is the case the hide rule always intended to allow.
• MembersSidebar deliberately keeps the stricter predicate. Deciding whether to add an agent to a channel is a different question from whether to mention one already in it.
• The new test pins the disagreement between the two predicates on that single input, so the gate isn't reinstated by someone reading isAgentIdentityInAllowedList as the obvious guard.
• Honest limitation: I could not write a test that fails if the gate is re-added at the call site. useMentions is a hook with a dozen queries and the repo has no hook-testing harness, so the protection here is a pinned-contract test plus a comment at the call site — documentation-grade, not enforcement.
• Out of scope, filed separately: that set-add-policy erases agent profiles, and that kind:10100 has no producer at all, are both upstream (block/buzz) problems. This PR only stops the desktop from hiding agents because of them.

Related issue

None found (fork).

Testing

• pnpm test: 4553 passed (1 new — asserts shouldHideAgentFromMentions shows a channel-member agent with no directory entry, while isAgentIdentityInAllowedList rejects the same input).
• pnpm exec tsc --noEmit: clean.
• pnpm check (biome + file-size + px-text + pubkey-truncation): clean, only the two known pre-existing infos.
• Verified live. Built a release bundle from this branch (--no-sign) and ran it against a real relay: an agent owned by another user, holding bot role in the channel and permitted by its owner, now appears in the @ picker. It was absent on main under identical conditions.

No screenshots — the change is the presence of a row in an autocomplete that requires a specific multi-user setup to reproduce.

🤖 Generated with Claude Code