Default "Fizz" agents from different users collide in one channel — mentions silently fork by pubkey

**Describe the bug**
A channel can end up with two separate agents that share the identical display name (both "Fizz"), with no warning to anyone. "Fizz" is a default agent bundled with Buzz, so each user has their own Fizz instance with a distinct pubkey out of the box — nobody creates or adds it. When two such users are in the same community, two different "Fizz" agents (different pubkeys, same name) are both present. Agent identity on Buzz is by pubkey, but @mentions resolve by display name on each client, so `@Fizz` silently forks: each person's client resolves the mention to whichever Fizz is in *their* roster — normally their own default one. Two people believe they are talking to the same agent, but they are not; mentions from one never reach the agent the other is talking to, and the two agents share no memory or conversation.

Observed: two Fizz agents in one channel — `3b565fde…` (Henry's default Fizz, channel owner) and `4fb0092f…` (Perry's default Fizz). Henry's `@Fizz` carries `p=3b565fde…`; Perry's carries `p=4fb0092f…`. The thread appears to "split" with no visible cause.

**Steps to reproduce**

1. Have two users who each have the default "Fizz" agent (each a distinct pubkey) join or share the same community.
2. Both default Fizz agents are now members of the community — same display name, two different pubkeys — with no collision warning.
3. User A types `@Fizz` and sends; user B types `@Fizz` and sends.
4. See the two mentions resolve to two different pubkeys (each user's own default Fizz), with no way to tell them apart in the composer.

**Expected behavior**
- Buzz warns, or otherwise disambiguates, when two agents sharing a display name (such as multiple users' default Fizz agents) are present in the same community.
- Stop agents teleporting into different communities - either as a setting, perhaps by default, or perhaps always.
- When a name is ambiguous, the mention is disambiguated (autocomplete shows managed-by/pubkey; the sent message renders the resolved identity), so `@Name` can never silently resolve to two different agents.
- Consider whether default agents should share one identity per community, or be visibly distinguished per user, so this collision does not arise by default.

**Version and platform**
- Buzz version: unknown
- OS: unknown

**Logs / additional context**
- Raw relay events: Henry's `@Fizz` mentions carry `p=3b565fde…`; Perry's carry `p=4fb0092f…`.
- Desktop autocomplete shows Henry's Fizz as "managed by me" and a distinct "managed by perry" Fizz; system line rendered "Fizz (bot) — managed by perry."
- Both are default Fizz agents, not agents either user deliberately created or added.
- Related issue seen in the same session (may warrant a separate report): a newly-shared agent (DBA) did not propagate to another member's client live, and the only surfaced workaround was "sign out," which wipes all local data.