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

[henry-putti]

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.

[matthewdcage]

Same-owner duplicate display names — team deploy path (#3639)

Your report: different users' default Fizz → identical display name, distinct pubkeys, silent @ fork.

Related path on upstream main, same user / same community: Deploy team to channel passes forceNewInstance: true for every persona (AddTeamToChannelDialog.tsx), so each redeploy mints a new owner-managed instance with the same persona display name. Filed as #3639 with repro on a single Desktop install.

Evidence

Repeated team deploy across channels → multiple Fizz/SEO/etc. pubkeys in buzz channels members output; @ resolution by display name becomes nondeterministic — same user-visible symptom class as your Henry/Perry repro, different trigger (team deploy vs default per-user Fizz).

Your suggested disambiguation (autocomplete shows owner + pubkey prefix; never silently fork) applies to both cases. Multi-user default-agent policy (#2910) is still a separate product question.