Desktop resolves typed @Name against all known profiles, not channel members — a removed duplicate identity still gets p-tagged, so remove-member cannot repair a mention collision

[ciscosurplus]

Environment

• Buzz Desktop v0.5.14, macOS (Darwin 25.4)
• Hosted relay wss://buzz.ngnc.net
• Same owner identity signed in on two Macs (which is how the duplicate agent identities arose — see [Bug] Second Desktop install creates duplicate agent identities, inflating channel membership #2648 / Secondary Desktop on the same identity auto-seeds/hosts the builtin Welcome Team, creating duplicate ghost agents that hijack @mentions #6211; this issue is about the repair path, not the minting)

Summary

When several agent profiles share a display name, Buzz Desktop resolves a typed @Name in a channel composer against every profile it knows about, not against the channel's current member list. So a duplicate identity that has been removed from the channel with buzz channels remove-member is still the one that gets p-tagged. The natural fix operators reach for (remove the ghost from the channel) therefore does nothing to mentions; the only working remedy today is renaming the ghost's display name.

The CLI behaves differently and, I think, correctly: buzz messages send resolves @Name against channel members and refuses to send on an ambiguous or non-member match.

Steps to reproduce

1. End up with two agent identities sharing display name Moneypenny (in our case one live key bebbcf8d… and one dead key 5e03b576… minted by a second Desktop whose runtime binary was missing — see Secondary Desktop on the same identity auto-seeds/hosts the builtin Welcome Team, creating duplicate ghost agents that hijack @mentions #6211).
2. Confirm both are members of channel X. Remove the dead one:
   buzz channels remove-member --channel <X> --pubkey 5e03b576… → succeeds; buzz channels members shows only the live key.
3. From Desktop, in channel X, type @Moneypenny hi and send.
4. Inspect the event: the p tag is 5e03b576… — the key that is no longer a member. The live agent is never woken.

Expected

Desktop resolves a typed mention against the channel's members (as the CLI does), and a non-member is never p-tagged. If a name is still ambiguous within the members, surface that rather than picking silently.

Actual

The removed identity is p-tagged. Removal from the channel does not change what the composer picks; only renaming the ghost's profile does.

Why it matters

Every duplicate-identity report (#2648, #5583, #6211, #5542) ends with the operator trying to clean up. Removing the ghost from channels is the obvious cleanup and it looks like it worked (roster is correct) while mentions keep going to the corpse. That silent mismatch cost us most of a day of debugging.

Related

#2648, #6211, #5583, #5542, #5264, RFC #5667