fix(desktop): allow cross-machine agent mentions

[Ansonhkg]

Summary

• allow agents managed on another machine to appear in @ autocomplete when they are members of the current channel
• preserve the existing respond-to policy check and keep non-member remote agents hidden
• route the selected agent pubkey as a Nostr p tag without trying to start the remote process locally
• add unit and desktop E2E regression coverage

Root cause

The mention pipeline correctly identified shared relay agents as invocable, but then applied a local-managed-agent filter before the policy-aware eligibility check. That removed every agent not managed by the current desktop, including valid members running on another machine. Manually typing the name did not restore the missing pubkey tag, so the remote ACP process never received the mention.

User impact

Users connected to the same community can now discover and invoke an in-channel agent from another machine, subject to that agent's existing respond-to policy.

Manual test

1. Started an agent on Machine A and set Respond-to to Anyone.
2. Added the agent and the Machine B user to the same channel.
3. Ran this branch on Machine B with just desktop-standalone.
4. Confirmed the remote agent appeared in @ autocomplete and responded after selection.

Validation

• just ci
• focused unit regression test
• focused Playwright smoke tests for remote-agent visibility, Nostr p-tag routing, and no local process start
• no new unwrap() or unsafe code
• no public API, event kind, endpoint, or configuration documentation required
• just test not run; this is a desktop-only change and does not modify relay, database, or auth behavior

Fixes #2508

[bayramog]

I validated this branch against a production same-owner/two-Mac failure on Buzz Desktop 0.5.3.

Production evidence (also posted on #3277): the secondary Mac's local keyless definition was enough to materialize a different local identity, attach that duplicate pubkey as the outbound p tag, and start local Hermes ACP. Once both keyed and keyless local records were removed, the real Mac-mini-hosted bot remained a channel member but disappeared from autocomplete. Addressing the hosted npub directly produced the correct p tag and ran only on the mini.

Local validation of this PR (8e85aa1aa):

• pnpm typecheck — pass
• complete desktop Node test run — 3332/3332 pass
• E2E build — pass
• focused Playwright smoke test mentioning a remote channel agent routes its pubkey without starting it locally — pass

The E2E assertion on both the signed p tag and unchanged start_managed_agent command count matches the two invariants that caught the real incident.

One regression extension would make the production trap explicit: seed the invoking client with no keyed or keyless local definition for the remote agent and assert the member candidate still appears. A keyless same-name definition must not be required as a discovery projection; in 0.5.3 it can be minted into a new local execution owner.

For our exact deployment, membership-based admission is the only currently functional path because the centrally hosted native Hermes identity is a real bot channel member but does not publish the desktop-managed kind:10100 directory record. Directory-only variants remain a no-op for that topology.