fix(desktop): enrich relay agent directory for @mention eligibility (#5363)

[rmichelena]

Fixes #5363.

Root cause: the data never reaches the eligibility layer

list_relay_agents (desktop/src-tauri/src/commands/agent_discovery.rs) builds the relay-agent directory from kind:10100 only. But an agent's respond_to policy is published as kind:30177 (KIND_MANAGED_AGENT, d-tag = agent pubkey) and its channel membership as kind:39002 (NIP-29 members list, one event per channel).

agents_from_events does parse respond_to / channel_ids when they happen to be embedded in the 10100 content — but agents that publish policy and membership in the dedicated 30177 / 39002 events arrive with respond_to: null and channel_ids: [].

Downstream, relayAgentCanRespondInChannel then returns false and shouldHideAgentFromMentions hides the agent — even for a channel member, and even for the agent's own owner. Owner-affected reproduces, which rules out the authorization branch as the sole cause.

This is why the symptom survives #4913: that fix (and the other open attempts) corrects the eligibility computation, but the directory feeding it is missing the policy and membership data in the first place.

Change

Rust (core fix) — new desktop/src-tauri/src/commands/agent_discovery/relay_enrich.rs:

• Enriches the kind:10100 directory by merging kind:30177 (policy, batched query) and kind:39002 (#p → channel_ids).
• kind:30177 is scoped by verified owners (kind:0 lookup) so a third party cannot spoof another agent's policy; unparsable or d-tag-less events are skipped with a tracing::warn!.
• Best-effort: a relay error during enrichment degrades to 10100-only rather than emptying autocomplete.
• Batch query limits are sized by event cardinality (39002 is one event per channel, not per agent).
• Unit tests for the merge/dedup helpers included.

Rationale for merging rather than requiring a fatter kind:10100: 39002 is the relay-authoritative NIP-29 membership (stronger than a self-reported channel_ids) and 30177 is the live policy event, so both are better sources than a snapshot baked into the profile.

TS (optional hardening, separate commits) — useComposerMentionableAgentPubkeys.ts, extracted out of useMentions.ts:

• Channel-membership fallback for the 39002 propagation window.
• Kept fail-closed: only admits respond_to: "anyone"; owner-only / allowlist agents stay hidden (covered by a test).
• Happy to drop these commits if maintainers prefer a Rust-only change.

Diffstat: 6 files, +812 / −46 (the bulk is the new relay_enrich.rs module and its tests).

Verification

• End-to-end on a self-hosted relay (wss://buzz.infinitek.pe, stream channel 273e2bad): before — remote/VPS-hosted agents absent from the @ list; after — all relay agents (including two VPS-hosted ones with respond_to: anyone) appear and mention delivery works. Confirmed by a human operator from a locally-built desktop client, with the mentioned agents receiving and replying to the events.
• pnpm --dir desktop check → exit 0
• pnpm --dir desktop typecheck → exit 0
• pnpm --dir desktop test → 4540 passed / 0 failed
• just desktop-tauri-fmt-check / desktop-tauri-clippy (-D warnings, --workspace --all-targets) / desktop-tauri-test → exit 0; 2282 passed / 0 failed in the main crate, including the 12 relay_enrich::tests (owner-verification, 30177 merge/dedup, 39002 #p grouping, query-limit sizing)
• desktop/scripts/check-file-sizes.mjs ratchet respected (that's why the Rust enrichment lives in its own module and the TS hook was extracted out of useMentions.ts).

Supersedes

Same symptom, eligibility-layer-only: #3292, #5084, #4603, #4517, #2693, #4047, #4137, #4546. #4546 touches the Rust types but not the directory query. Those patches are compatible with this one but are not sufficient on their own, because the respond_to / channel_ids they branch on are still null / [].