fix(desktop): discover remote channel agents

[reynaldomarques-hrt]

Channel members that are agents now remain eligible for mention autocomplete even when the current desktop has no local managed-agent record or relay-directory metadata for them. This lets users mention agents hosted on another desktop without copying the agent's runtime, credentials, or configuration to the desktop they are currently using.

The existing invocability guard still hides a channel-member agent when relay metadata explicitly says that the current user cannot invoke it. A regression test covers admission of remote channel members alongside the existing exclusion tests.

Verification

• Desktop unit suite: 4,392 passed
• TypeScript typecheck: passed
• Desktop checks: passed with existing informational notices in unrelated files

🤖 Generated with Compound Engineering

[rmichelena]

Heads-up from a parallel investigation on #5363, in case it's useful here.

The respond_to / channel_ids fields this patch branches on are null / [] for any agent that publishes its policy as kind:30177 and its channel membership as kind:39002 — because list_relay_agents (desktop/src-tauri/src/commands/agent_discovery.rs) queries only kind:10100. So the eligibility logic here can be correct and the agent still stays hidden, even for its own owner, since the directory feeding it never carries the data.

We opened #5483 with a data-layer fix: merge kind:30177 (policy, owner-verified) and kind:39002 (NIP-29 membership) into list_relay_agents, best-effort so a relay error degrades to 10100-only instead of emptying autocomplete. E2e-verified on a self-hosted relay.

Not a claim that this PR is wrong — the two layers are compatible — just that the eligibility change alone may not be reproducibly verifiable against relay-published agents. Full analysis in #5363.

[reynaldomarques-hrt]

Thanks feel free to close this item as needed.

[rmichelena]

Cross-linking from #5483, and flagging a trust-model consequence I think is worth a second look before this lands.

return (
  candidate.isAgent !== true ||
  candidate.isMember === true ||          // ← new
  allowedAgentPubkeys.has(normalizePubkey(candidate.pubkey))
);

isMember === true short-circuits before the allowed-list check, so any agent that is a channel member becomes mentionable — including one whose kind:10100 says respond_to: "owner-only" or an allowlist the viewer isn't on. That's the policy the picker exists to enforce; shouldHideAgentFromMentions can't recover it either, since it returns false on its first check for anything already admitted here. The symptom goes away, but so does the guard.

It also only reaches the composer: the DM picker (useNewMessageRecipients.ts) and add-member search (MembersSidebar.tsx) use community scope, which has no member set to consult, so those agents stay un-DM-able and un-addable.

Root cause we traced for #5363: list_relay_agents builds the directory from kind:10100 only, while respond_to is published as kind:30177 and membership as kind:39002 — so relay agents arrive respond_to: null / channel_ids: [] and the eligibility layer is judging on absent data. #5483 fixes it there, which also fixes the two community-scope surfaces, and keeps owner-only agents hidden (pinned by tests).

Would you consider closing in favor of #5483? Maintainers' call — but I'd argue the membership bypass shouldn't land as-is either way.

[reynaldomarques-hrt]

Thanks for the deeper analysis. I'm comfortable closing this PR in favor of #5483.