fix(desktop): allow in-channel relay agents in mention autocomplete

[EliteSystemsAI]

Problem

The desktop mention picker rejects every identity classified as an agent unless that identity also exists in the local managed-agent store. A relay-hosted agent can therefore be an authoritative member of the open channel and still be impossible to tag from another desktop installation.

This makes remote agents look offline or absent even though the relay membership and agent profile are valid.

Fix

Treat authoritative channel membership as sufficient autocomplete eligibility. Relay-only agents outside the current channel remain subject to the existing discovery and policy filters.

Regression coverage

Adds a focused test proving that an in-channel relay agent is eligible without a local management record.

Verification

• pnpm build
• pnpm exec biome check src/features/agents/lib/agentAutocompleteEligibility.ts tests/e2e/mentions.spec.ts
• focused Playwright regression test passes
• git diff --check

Signed-off-by: EliteServer eliteserver@EliteServers-Mac-mini.local

[EliteSystemsAI]

@baxen @atishpatel could you please review this small desktop autocomplete fix? It addresses a production case where a relay-hosted agent is already an authoritative channel member but remains impossible to tag because the client requires a local managed-agent record. The focused regression, desktop build, Biome checks, Semgrep, zizmor, and DCO are green.

[tlongwell-block]

The production fix is small and the live behavior is correct, but the regression coverage does not exercise the bug.

mentions.spec.ts is a Playwright UI spec, yet the new test directly imports and calls isAgentIdentityInManagedList. It would remain green if useMentions stopped passing member candidates through that helper, stopped setting isMember, or otherwise broke the autocomplete call path.

I reproduced the intended behavior against a real local relay at this exact head: the seeded relay-only bot member is absent from autocomplete at base eb049ddf815d48195e1713afe039d28c950d7933 and present at head faa43cac9c9f57f6503ea515010ab8023398d461.

Please replace or supplement the predicate assertion with a UI-level regression: install the bridge with an in-channel relay-classified agent omitted from managedAgents, type @ into the composer, and assert its mention option is visible. That can use the mock bridge if a live-relay test is too costly for CI; the important part is covering useMentions through the rendered autocomplete.

[tlongwell-block]

Follow-up after an independent review surfaced a missed failure: I reproduced the existing rendered-autocomplete test on both exact revisions.

• base eb049ddf815d48195e1713afe039d28c950d7933: passes
• head faa43cac9c9f57f6503ea515010ab8023398d461: fails at mentions.spec.ts:227; alice count is 1, expected 0

This strengthens my request-changes review. The patch changes behavior for every relay-classified channel member, not only the intended relay agent, and that semantic expansion currently contradicts an existing UI expectation. It also leaves a gate-ordering inconsistency: an invocable shared relay agent that is not a current-channel member is rejected by isAgentIdentityInManagedList before shouldHideAgentFromMentions can apply its "invocable => show" policy.

Please resolve the existing UI failure and consolidate the eligibility policy rather than adding another responsibility to isAgentIdentityInManagedList. The pure predicate case should also live in agentAutocompleteEligibility.test.mjs; the actual bug needs rendered-autocomplete coverage.

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

[rmichelena]

Cross-linking from #5483 — same trust-model note I left on #5084, since the change is equivalent.

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

isMember === true short-circuits the eligibility check entirely, so a channel-member agent whose kind:10100 says respond_to: "owner-only" (or an allowlist that excludes the viewer) becomes mentionable by everyone in the channel. The added e2e assertion pins exactly that: an agent with an empty allowed set admitted purely on membership.

Two other things: isAgentIdentityInManagedList no longer exists on main (#4913 replaced that call site with isAgentIdentityInAllowedList over the mentionable set), so the patch is also stale; and the fix only reaches the composer — the DM picker and add-member search run in community scope with no member set to consult.

The underlying cause of #5363 sits below all of this: list_relay_agents queries kind:10100 only, while respond_to lives in kind:30177 and membership in kind:39002, so relay agents arrive respond_to: null / channel_ids: []. #5483 fixes the directory and keeps owner-only hidden.

Would you consider closing in favor of it? Maintainers' call.