fix(desktop): allow channel member agents in mentions

[satsdisco]

Summary

Fixes Desktop mention resolution for remote/shared managed agents that are already channel members but are not owned by the local Desktop.

The verified user-facing failure was: Satsdisco could see a remote managed agent, Fizz, as a channel member, but typing @Fizz did not produce the agent p tag. Another user's @Fizz message did include Fizz's p tag, which narrowed the issue to local Desktop mention candidate filtering/resolution rather than relay delivery.

Root Cause

Desktop mention autocomplete had two related assumptions that broke for remote managed agents:

• Agent identities from search/autocomplete were filtered unless they were in the local managed-agent list.
• Channel-member agents could still be hidden when relay-directory invocability data made them look non-invocable/owner-only.

That is too strict for shared channel usage. Channel membership is the concrete signal that the identity can be mentioned in that channel. Whether the remote agent actually responds is still enforced by the receiving agent/relay policy.

Changes

• Keeps channel-member bots/agents visible in mention autocomplete even when they are remote managed agents.
• Counts channel-member bots as known agent pubkeys during message mention resolution, so selected mentions emit the correct agent p tag.
• Scopes relay-directory mentionability to the active channel so shared relay agents from other channels do not leak into the current channel's autocomplete.
• Adds coverage for active-channel scoping, allowlist channel placement, remote allowed agent identities, and channel-member agents with non-invocable directory entries.

Validation

Validated at commit cff618911b0c26d810055cb1b787f3cc487ffed5:

• corepack pnpm --dir desktop test - 3,374 passed, 0 failed
• corepack pnpm --dir desktop typecheck
• corepack pnpm --dir desktop build

Also validated manually via the replacement DMG: typing @Fizz from Satsdisco now works and emits the intended mention behavior.

[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.