[Bug] Remote managed agents are hidden and unmentionable on secondary devices

## Summary

A cloud-connected managed agent that runs on Mac A is not visible or mentionable from Buzz Desktop on Mac B, even when both desktops use the same community/account and the agent is already a member of the channel.

The agent is visible and mentionable on Mac A. On Mac B, direct messages to the agent work, but the agent is absent from the channel member/mention UI.

This appears to couple two separate concepts:

1. discovering/mentioning a remote cloud agent; and
2. owning and launching that agent's local runtime.

## Environment

- Buzz Desktop 0.4.21
- macOS on both machines
- Same hosted Buzz community and same human identity/account
- Agent runtime (`buzz-acp` with an OpenClaw ACP adapter) runs only on Mac A
- Agent is connected to the hosted relay, online, and subscribed to the channel

## Steps to reproduce

1. On Mac A, create/configure a managed ACP agent and connect it to a hosted Buzz community.
2. Add the agent to a channel as a bot member.
3. Confirm on Mac A that the agent appears in the channel and responds to `@mentions`.
4. On Mac B, sign in to the same hosted community with the same human identity/account.
5. Open the same channel and type `@`.

## Actual behavior

- Mac B does not show the remote agent in the mention/member UI.
- Other agents present in Mac B's local `managed-agents.json` are shown (including agents marked "not in channel").
- The missing remote agent is nevertheless reachable by direct message from Mac B.
- Relay/channel membership is correct, and the remote runtime on Mac A is online.
- Restarting Buzz Desktop on Mac B does not fix the problem.

As a diagnostic experiment, adding a keyless/inactive record for the remote agent's public key to Mac B's local `managed-agents.json` makes the agent appear in `@` autocomplete. However, mentioning it then makes Buzz attempt to start the agent locally on Mac B and produces a warning that the OS keyring may be unreachable. Mac B does not possess the agent's private key by design.

This diagnostic record was not intended as a supported workaround; it demonstrates that mention visibility is gated by local managed-agent ownership and that mention dispatch then invokes the local lifecycle path.

## Expected behavior

- Any agent that is a member of the current hosted channel should be visible and mentionable from every signed-in client authorized to view that channel.
- Only the machine that owns the agent's private key/runtime configuration should be able to start, stop, or reconfigure the runtime.
- Mentioning an online remote agent should send the mention to its existing remote runtime; it should not require a local `managed-agents.json` record or local keyring entry.

In short: remote visibility/invocation should be separate from local runtime ownership.

## Impact

This breaks the primary multi-device workflow: a user cannot reliably communicate with agents running on an always-on Mac mini from another Mac, despite using the same hosted community and despite the agents being online and channel members.

It also creates a dangerous UX ambiguity: attempting to restore visibility with a local definition causes the second client to try to launch a duplicate runtime and ask for keyring access.

## Suggested direction

- Build mention candidates from hosted channel membership/profile data, not only local managed-agent definitions.
- Represent remote agents as non-owned/non-launchable entities on secondary clients.
- Route mentions to the hosted agent identity without calling the local managed-agent start path.
- Keep lifecycle controls gated on possession of the local private key/runtime definition.

## Related issues

- #1743 covers mentions to offline agents, but not cross-device discovery of an online remote agent.
- #1609 covers unavailable keyring UX, but not the incorrect local-launch attempt for a remote agent.
- #2157 discusses duplicated/local agent definitions, but not hosted-agent visibility across devices.