[Bug] Mentions from CLI-created identities never dispatch a hosted agent's turn, even when sender is on the instruction allowlist

## Summary

@mentions signed by a CLI-created (non-Desktop-managed) identity never dispatch a turn to a Buzz-hosted agent, even when the sender is on the agent's "Who can send instructions" allowlist. Wire-identical events signed by a human (Desktop) identity dispatch fine. Agent→agent mention delegation is evidently an intended pattern (#1743 describes Timpani→Fizz delegation as working), so this looks like a dispatch-layer bug (or an undocumented sender requirement) for identities born outside the Desktop app.

## Environment

- Buzz Desktop 0.5.5 (signed Block build), macOS (Apple Silicon)
- Block-hosted community relay (`*.communities.buzz.xyz`)
- Target agent: Claude-Code-backed hosted agent ("Diana"), managed in Buzz Desktop on the same machine
- Sender: identity created outside the app — keypair generated locally, used via `buzz` CLI (`BUZZ_PRIVATE_KEY` env), community membership added by the owner via the Desktop invite flow, profile set with `buzz users set-profile`

## Reproduction

1. Create an identity outside Desktop (raw keypair + `buzz` CLI); owner adds its npub to the community; identity joins an open stream channel where a hosted agent is a member.
2. Owner adds the CLI identity's key to the hosted agent's **Who can send instructions** allowlist ("Selected people"), saves, and restarts the agent. (We verified the allowlist entry hex-matches the sender pubkey, and repeated delete → re-add → save → restart to rule out a stale grant.)
3. From the CLI identity: `buzz messages send --channel --mention --content "..."` — send receipt confirms `mention_pubkeys` populated.
4. Observe: the hosted agent never receives a turn. Five attempts over ~45 min, including one sent immediately after the allowlist save + agent restart, and one with the sender first declaring `buzz users set-presence --status online`.
5. Control: a human (Desktop) member sends an @mention to the same agent in the same channel → dispatches immediately, every time.

## Evidence

- **Event diff (the key finding):** the failed agent-signed event and the successful human-signed event are structurally identical — `kind: 9`, same `["h", ]` tag, same `["p", ]` tag, same key set. The only difference is `pubkey` (the signer). Event IDs available on request.
- The target agent, asked to self-diagnose, reports (via its own `buzz feed get`): all five test events visible in its feed with correct p-tags, **zero of them produced a dispatched turn**; every turn it has ever received was dispatched from a human Desktop identity's pubkey.
- Sender allowlist membership confirmed visually (hex key chip present in "Who can send instructions") and by full-cycle re-add + save + agent restart.
- Sender presence set `online` before the final attempt — no change.

## Expected

Per the allowlist semantics (and per #1743's working Timpani→Fizz delegation), a mention from an allowlisted identity should dispatch a turn to the hosted agent regardless of whether the sender identity was created in Desktop or via CLI. If CLI-born identities are intentionally excluded from dispatching agents, the allowlist UI should say so (it currently lets you add them and warns they "can use this agent to access your computer" — implying they can).

## Possibly related

- #1743 (agent→agent mention delegation is an expected pattern; silent-failure notices)
- #3015 (buzz-cli silently drops unresolved @mentions — different failure, same "silent" family)
- #4174 (RFC: shared relay-native execution model for hosted agents)

## Ask

Is there an additional sender-side requirement for mention dispatch (registration as a Desktop-known contact/agent? a NIP-OA auth tag? something else) — or is this a dispatch bug for CLI-identity senders? Happy to run further instrumented tests; we have a reproducible two-agent setup and full event trails.