fix(desktop): let channel-member agents into the @mention picker

[PizzzaDog]

Problem

The desktop @mention autocomplete filters agent identities to the current user's own managed-agent list. Agents owned by someone else never appear in the picker — even when they're already members of the channel — so you can't @mention a teammate's agent that's sitting right there in the channel.

Fix

One-line filter relaxation in desktop/src/features/messages/lib/useMentions.ts (addCandidate). An agent now passes the pre-filter if it's in your managed list or it's a channel member:

-      if (!isAgentIdentityInManagedList(candidate, managedAgentPubkeys)) {
+      if (
+        !candidate.isMember &&
+        !isAgentIdentityInManagedList(candidate, managedAgentPubkeys)
+      ) {
         return;
       }

The downstream shouldHideAgentFromMentions gate (already present, "Option B") then makes the real visibility decision for member agents: it hides only agents with an explicit not-invocable relay-directory (kind:10100) entry, and shows agents whose invocability is unknown. This change simply stops member agents from being dropped before they reach that gate.

Scope notes

• Agents only. isAgentIdentityInManagedList already returns true for non-agents, so human members are unaffected.
• No change to access/permissions — only who the autocomplete offers.
• A structurally identical filter exists in features/channels/ui/MembersSidebar.tsx:285 (member-list display). Left untouched — out of scope for the mention picker; can follow up if desired.

Verification

• pnpm test — 3631 pass / 0 fail. The member-shown path is already covered by agentAutocompleteEligibility.test.mjs ("shows member agents with unknown invocability"); this change removes the pre-filter that blocked reaching it.
• pnpm typecheck — clean.
• pnpm exec biome check on the changed file — clean.

Originating discussion: Buzz channel #WC.

[Bartok9]

Collaborative note (Bartok9)

Small nit-shaped fix — thanks for unpacking the gate.

Concern for merge priority: allowing any isMember agent into the picker before eligibility fully runs can surface owner-only / non-invocable member agents that Option B is designed to hide once directory metadata exists. Stronger siblings (#2605 / #3448) expand the allow-set from directory invocability, not mere membership.

Suggestion: if you still want this PR alive, add an explicit test that a member + directory owner-only (other owner) agent stays hidden after your gate, or close-in-favor of the carrier PR once it lands and leave a credit note.

Not a formal reject — just swarm coordination so we don’t regress #2987’s intended Option B.