Mention autocomplete hides agents that are channel members but managed by another install

**Setup.** Two people, two Macs, one shared channel. One person runs agents Scout and Emmy on their Mac. The other runs agent Prinny on theirs. All three publish kind:0 profiles, are members of the channel with role `bot`, and are configured `respond_to: anyone`.

**Expected.** Each person can `@` any agent in the channel.

**Actual.** Each person's mention autocomplete offers only the agents managed by their own install. Neither can reach the other's agents from the GUI at all, because a mention with no resolved pubkey carries no `p` tag, and the `p` tag is what wakes an agent.

**Cause.** In `desktop/src/features/messages/lib/useMentions.ts:249`, every candidate passes through:

```ts
if (!isAgentIdentityInManagedList(candidate, managedAgentPubkeys)) {
return;
}
```

`managedAgentPubkeys` is derived solely from `useManagedAgentsQuery()` (`useMentions.ts:163`), which calls the `list_managed_agents` Tauri command. That command reads local disk records only (`desktop/src-tauri/src/commands/agents.rs:524` -> `load_managed_agents`). So any candidate with `isAgent === true` whose pubkey is not a locally managed agent is dropped before anything else runs.

This appears intentional: `agentAutocompleteEligibility.test.mjs:139` asserts it as "keeps people and only current managed agent identities".

**Why it looks worth revisiting.** The permissive path for exactly this case already exists and is currently unreachable for remote agents:

- `getMentionableAgentPubkeys` (`agentAutocompleteEligibility.ts:33`) already unions locally managed agents with relay-directory agents that pass `relayAgentIsSharedWithUser` (`respond_to: anyone` plus a shared channel, or an allowlist naming the current user).
- `shouldHideAgentFromMentions` (`agentAutocompleteEligibility.ts:67`) already has a documented "Option B" branch for member agents, showing them unless the kind:10100 directory explicitly excludes the current user.
- `useMentions.ts:334` iterates `relayAgentsQuery.data` and adds those agents as candidates.

All three are gated out by the managed-list check that runs first, so a remote agent can never reach them.

**Proposed change.** Let the managed-list check admit agents that `getMentionableAgentPubkeys` already considers invocable, i.e. run the eligibility test before the ownership test rather than after. Concretely, drop an agent identity only when it is neither locally managed nor in `mentionableAgentPubkeys`. The invocability signal (`respond_to` plus shared channels, via kind:10100) is the right authority for this, and it is already computed.

**Impact.** Without this, multi-person multi-agent collaboration in a shared channel only works if every human relays through their own agent. That works, but it means a human can never directly address a teammate's agent.

**Verified against:** upstream `main` @ b1b283c, desktop 0.5.3.

Related: #4487 / #4488 (same two-Mac setup, separate `respond_to` propagation bug).

Start in desktop/src/features/messages/lib/useMentions.ts and trace the eligibility helpers in agentAutocompleteEligibility.ts, then read agentAutocompleteEligibility.test.mjs around the managed-agent assertion. Verify that shared remote agents appear in mention autocomplete while non-invocable agents remain hidden, and add or update regression coverage for the two-install shared-channel case.

Written by the indexing model from the issue text.