Agent runtime mis-reports a community-scope rejection as a "self-attestation / owner and agent keys are identical" error; @-mention picker offers cross-community agent instances with no community indicator

### Environment
- Buzz Desktop **v0.5.17**, macOS **26.3.1**
- Hosted relays: `wss://{chicago,headless,deadrop}.communities.buzz.xyz` (three communities in one Desktop install)
- Built-in agents (Fizz/Honey/Bumble) with per-community instances

### Summary
Two related problems combine to make a benign, correct configuration look like a broken-keygen / self-attestation bug, costing significant diagnosis time.

1. **The agent runtime emits a misleading error.** When an agent instance scoped to community A is invoked in a channel belonging to community B, the relay (correctly) does not accept its delegated event. The agent's model surfaces this to the user as: *"Buzz still rejects the send with the same self-attestation error: the configured owner and Honey agent keys are identical."* **This is false.** The owner and agent keys are provably distinct.

2. **The @-mention picker offers agent instances scoped to other communities**, with no indication of which community/relay each belongs to — so a user can mention a Honey that structurally cannot post in the current channel. (Distinct from [#2717](https://github.com/block/buzz/issues/2717), which covers the *Settings* UI; this is the *compose-time mention* picker.)

### Why the error message is wrong (evidence)
Per the data model ([#2717](https://github.com/block/buzz/issues/2717)), managed agents are stored as "one definition record per persona plus one instance record per community/relay." On this install, `managed-agents.json` holds three legitimate, correctly-distinct Honey instances:

| pubkey (agent) | relay / community | owner (from auth_tag) |
|---|---|---|
| `064573dce69c62c6…` | headless.communities.buzz.xyz | `bb9012bdc32eb5a6…` |
| `16950f6b6780111a…` | deadrop.communities.buzz.xyz | `bb9012bdc32eb5a6…` |
| `e044a83985bb42ef…` | chicago.communities.buzz.xyz | `bb9012bdc32eb5a6…` |

Every `buzz-acp` startup log confirms owner ≠ agent, e.g.:

```
INFO buzz_acp: buzz-acp starting: relay=wss://chicago.communities.buzz.xyz pubkey=e044a83985bb42ef343cba347f1b7f8b4138a4f0839efe1d4158bd166060fd0b …
INFO buzz_acp: agent owner: bb9012bdc32eb5a663bd888f4c0568241226b5eeb28f2c90c864f3cf3a8a7726
```

`grep -riE "self.?attest|identical|same.*key"` across all agent logs returns **nothing** — the phrase originates in the agent model's paraphrase, not in relay/harness output. There is no self-attestation and no keygen defect.

### Impact
The misleading string sends users (and anyone they hand off to) chasing a non-existent keygen/delegation bug — including the tempting but wrong "fix" of minting a new key via `buzz-admin generate-key` and setting `BUZZ_PRIVATE_KEY`, which just creates a *fourth* instance and worsens the cross-community fan-out.

### Expected
- When a delegated event is rejected/ignored due to community scope, the surfaced error should say so (e.g. "this agent instance belongs to community X and cannot post in community Y"), never "owner and agent keys are identical."
- The @-mention picker should either scope to instances valid in the current community, or clearly label each candidate's community/relay.

### Related
- [#2717](https://github.com/block/buzz/issues/2717) — per-community agent instances collapsed to one list entry; Settings UI can't target the right instance (same data-model root, different surface)
- [#4147](https://github.com/block/buzz/issues/4147) — agents binding to a different relay community than the owner (loopback host-normalization; same *failure shape*, different root cause — ours is hosted)
- [#5449](https://github.com/block/buzz/issues/5449) — agent needs harness restart to be discovered in a new channel

### Repro
1. Add the same built-in agent (e.g. Honey) while active in two+ different communities → one instance per community is created (correct per [#2717](https://github.com/block/buzz/issues/2717)).
2. In a channel in community A, `@`-mention Honey; pick the instance the picker offers (may be the community-B/C instance — picker doesn't disambiguate).
3. Ask it to post. It fails and reports the "self-attestation / identical keys" error, despite keys being distinct in the logs.

Start by reproducing the cross-community mention flow and inspect managed-agents.json alongside the buzz-acp startup logs to distinguish relay-scope rejection from key errors. Trace the compose-time @-mention picker and the agent runtime's surfaced error. Done means invalid community instances are filtered or labeled, and scope rejection is reported accurately without implying identical keys.

Written by the indexing model from the issue text.