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.