fix(desktop): surface eligible relay agents in @mention

[w3bsited3v]

Summary

Desktop @mention autocomplete drops shared relay agents — agents owned by
another identity, e.g. a relay-hosted agent run by a separate operator and
shared with a team. useMentions filters candidates through
isAgentIdentityInManagedList, which only keeps agents present in the
viewer's own local managed-agents store. So an eligible relay agent is
never offered in @-autocomplete, even though the + New-DM picker lists it
and DMs to it work.

The mobile client's buildMentionCandidates
(mobile/lib/features/channels/mentions/mention_candidates.dart) has no
such gate — it has no local agent store — and already surfaces any relay
agent that is anyone and shares a channel with the viewer. This change
brings desktop in line: keep an agent candidate when it is either locally
managed or already eligible via mentionableAgentPubkeys (i.e. it passed
relayAgentIsSharedWithUser). Eligibility semantics are unchanged — the fix
only stops the managed-list filter from dropping already-eligible relay
agents.

Related issue

Fixes #4128. Related: #3971, #3125, #3776.

Testing

Verified against a self-hosted relay: a shared, relay-hosted agent
(respond_to=anyone, joined to a channel the viewer is a member of, with a
kind:10100 directory entry) now appears in desktop @-mention autocomplete,
matching the mobile client. Previously it was reachable only via the +
New-DM picker.

• No change for locally-managed agents or non-agent identities (they still
  pass isAgentIdentityInManagedList).
• Reuses the existing mentionableAgentPubkeys set, so no new eligibility
  path is introduced.

Happy to add a focused test if you'd like — the current
useMentions.test.mjs only covers the hasMention string helpers, so the
candidate-assembly path isn't unit-tested today; let me know your preference
for structuring one.

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