fix: use relay-eligible agents for mention autocomplete

[auctobot001]

Summary

• useMentions.ts filtered agent candidates for @-mention autocomplete through managedAgentPubkeys — the set of agents locally managed by the current device — instead of mentionableAgentPubkeys, which already accounts for relay-directory + allowlist eligibility.
• Practical effect: on a multi-device setup, an agent only appears in mention autocomplete on the device that created/manages it. Other devices whose identity is allowlisted and who share the channel can't tag the agent at all, even though the agent is fully eligible per the relay directory (kind:30177) and channel membership.
• Swapped the set used in the isAgentIdentityInManagedList check from managedAgentPubkeys to mentionableAgentPubkeys. managedAgentPubkeys was then unused in that useMemo, so it's dropped from the dependency array (flagged by the exhaustive-deps lint).

Test plan

• pnpm typecheck — clean
• pnpm exec biome check on the changed file — clean
• pnpm test — all 3870 unit tests pass
• Manual repro: create a managed agent on device A, allowlist device B's pubkey, add the agent to a shared channel; confirm the agent now appears in device B's mention autocomplete

[rsaulo]

We hit this exact bug from a different angle than the multi-device scenario described above — a fully remote agent with no managed-agents entry on any desktop:

• The agent (Hermes-based, running headless on a VPS) connects to our relay over WS with NIP-OA delegated auth (it is not a direct relay member; the owner is).
• It publishes a relay agent profile with respond_to: "anyone" and channel_ids covering a channel shared with the user, so relayAgentIsSharedWithUser returns true and it lands in mentionableAgentPubkeys.
• The picker still never shows it: the isAgentIdentityInManagedList pre-filter in addCandidate drops the candidate before shouldHideAgentFromMentions (which would keep it) ever runs. Since the agent is managed on no desktop anywhere, there is no device where it can be mentioned via autocomplete.
• Typing the literal @Name as plain text works fine — the downstream matching is healthy, it's only the candidate pre-filter that's wrong.

This also means the "Option B" logic inside shouldHideAgentFromMentions is currently dead code for any non-locally-managed agent, which matches what this PR's one-line swap fixes: mentionableAgentPubkeys is already the superset that accounts for directory + allowlist eligibility.

We've cherry-picked this diff onto desktop-v0.5.5 and are running it as a local patch; happy to report back with confirmation from that build. Would love to see this merged — for remote/relay-directory agents there is no workaround on the user side.

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