Relay-discovered agent with respond_to=anyone still never appears in @-mention autocomplete (regression/incomplete case of #4913)

### Summary

After PR #4913 ("fix(desktop): allow shared agent mentions", merged into `main` 2026-08-05) was expected to let non-owners `@`-mention a relay-discovered agent when its `respond_to` policy authorizes them, the agent still never appears in the `@`-mention autocomplete — even when every precondition the fix relies on is independently confirmed correct on the relay.

This reproduces with **two independent agents, two different owning accounts, and two different channels**, so it isn't specific to one agent's config.

### Environment

- Buzz Desktop: 0.5.8 (macOS), built from a commit including #4913
- Relay: self-hosted, upgraded to current `main` (`5bf78671f`) specifically to rule out a version gap — no change
- Both the mentioning user and the agent owner are members of the same community

### Repro steps

1. Owner A creates/edits an agent, sets "Who can talk to this agent" to **Anyone** via **channel members sidebar → agent card → "Manage agent access"** (not the top-level Edit Agent dialog, which is the known #2501 persistence bug).
2. Confirmed via the relay's own event log that this actually published a fresh `kind:30177` event with `"respond_to":"anyone"` (superseding the prior `owner-only` event) — see raw events below.
3. Agent is added as a member (`role: bot`) of a `stream`-type channel.
4. A different user (not the agent's owner), already a genuine member of that same channel, opens the channel and types `@` + the agent's name.
5. **Expected**: agent appears in the autocomplete per #4913's stated behavior ("admit relay-discovered agents to autocomplete when their response policy authorizes the viewer... require authorization in the exact active stream/forum channel for mentions").
6. **Actual**: agent never appears, regardless of search string used (tried exact name substrings that should match, e.g. typing "ben" against an agent named "Bens Fizz").

### Confirmed NOT the cause (ruled out one at a time)

- **Relay code version** — upgraded relay from a pre-#4913 commit to current `main`; no change.
- **`respond_to` not actually persisting** — verified directly against the relay's Postgres `events` table (not the Desktop UI) that a `kind:30177` event with `respond_to: "anyone"` was published and is the latest event for the agent's `d`-tag.
- **Channel membership** — verified via `channel_members` that the agent has an active (`removed_at IS NULL`) `bot` row in the exact channel, and the mentioning user has an active `member` row in the same channel.
- **Channel type** — verified `channel_type = 'stream'` (the type #4913 explicitly scopes exact-channel mention authorization to).
- **Relay connectivity** — confirmed active websocket connections from the mentioning user's client in the relay's own connection logs at the time of testing.
- **Relay-side access control** — read `get_accessible_channel_ids` directly (`buzz-db/src/channel.rs`): grants access via real membership OR open-visibility fallback; both users have real membership rows, so the relay has no basis to withhold channel-scoped events.
- **Stale local client cache** — fully quit the app, cleared `~/Library/Caches/xyz.block.buzz.app` and `~/Library/WebKit/xyz.block.buzz.app` (WebView cache/IndexedDB/localStorage), relaunched. Same result. (Note: this cache also apparently held session/identity data not backed by the Keychain-stored secrets — recovered via the existing-key flow, but worth flagging separately: clearing WebView storage shouldn't be able to desync a user from their Keychain-stored identity in the first place.)

### Raw evidence

Relay `events` table, latest two `kind:30177` rows for one of the test agents (pubkey redacted per-agent, available on request):
```
{"name":"Grokola","persona_id":"7f87a3ac-aaa7-4c59-8d44-032846410fa1","parallelism":10,"respond_to":"anyone"} | 2026-08-08 23:47:24+00
{"name":"Grokola","persona_id":"7f87a3ac-aaa7-4c59-8d44-032846410fa1","parallelism":10,"respond_to":"owner-only"} | 2026-08-08 09:15:31+00
```

`channel_members` for the same channel:
```
channel_type = stream
role=bot removed_at=NULL
role=member removed_at=NULL
```

### Suspected area

Given every server-side precondition is verifiably correct, this points at the client-side eligibility computation in `desktop/src/features/agents/lib/agentAutocompleteEligibility.ts` / `desktop/src/features/messages/lib/useMentions.ts` (added/modified in #4913) — possibly in how `relayAgentsQuery` data is fetched/kept fresh, or in `getMentionableAgentPubkeys`'s channel-scoped branch (`relayAgentCanRespondInChannel`). I wasn't able to get a live JS-console trace to pin down the exact line (release build has no reachable WebView inspector — Safari's Develop menu shows "No inspectable applications," and no in-app devtools shortcut/setting was found either), so filing with full server-side evidence instead in case someone with build access can reproduce with `pnpm --dir desktop dev` and step through it directly.

### Related

- #2950 (original picker-visibility report this traces back to)
- #2501 (respond_to persistence bug — ruled out here since we verified the published event directly, but worth keeping in view since it's the same feature area)
- #4913 (the fix this appears to be a regression in / incomplete case of)