Stale agent memberships permanently pollute one-to-one DMs

[andynguyenhuu]

Describe the bug

A two-party DM can become permanently polluted after bot members are added. If some of those bots later become stale or fall outside the current local managed-agent registry, the human owner cannot remove them in Buzz Desktop. Starting a new DM with the original agent reopens the polluted channel, and outgoing messages continue to carry recipient p tags for the stale bots.

This produces two related failures:

1. The member UI recognises the stale profiles as agents managed by the current human, but hides the channel-removal action.
2. The original two-party DM lookup continues to resolve to the channel after its live membership has expanded, so the user cannot create or reopen a clean one-to-one DM.

Steps to reproduce

1. Open a one-to-one DM between a human and an agent.
2. Add several bot agents to that DM.
3. Remove locally managed active bots from the member sidebar.
4. Leave at least one owner-managed bot represented only by a stale or relay profile, not the current local managed-agent registry.
5. Open that stale bot's profile from the DM. The profile shows that the agent is managed by the current human and offers Archive agent, but neither the member list nor the profile's Channels tab offers Remove from channel.
6. Start a new DM with the original agent. Buzz reopens the polluted DM.
7. Send a message addressed only to the original agent. The event still includes recipient tags for the stale bots.

Expected behavior

• A human owner should be able to remove any agent the relay declares they own, even if that agent is not in the current local managed-agent registry.
• Reopening a one-to-one DM should not silently return a channel whose active participant set contains additional members.
• Outgoing DM recipient tags should represent the intended active participants, not stale participants retained by an old lookup record.
• Removing the stale memberships should preserve the existing message history.

Version and platform

• Buzz version: 0.5.11, confirmed latest by the in-app updater
• OS: macOS 27.0 (26A5406e)

Logs / additional context

Live readback shows four active channel memberships: the human, the intended agent, and two stale bots. No private channel UUIDs or pubkeys are included in this public report. The exact two membership targets are available privately for an operator repair.

Observed behaviour and source paths:

• desktop/src/features/channels/lib/useClassifiedMembers.ts: isMyBot checks only managedAgentPubkeys.
• desktop/src/features/channels/ui/MembersSidebar.tsx: canRemoveMember depends on elevated channel role or isMyBot(member), so an ordinary DM member cannot remove a stale relay-owned agent.
• crates/buzz-db/src/dm.rs: open_dm resolves an existing DM by its stored participant hash, which can continue to point at a channel after later membership expansion.
• desktop/src/features/messages/lib/messageMentionPubkeys.ts: DM recipients are the union of explicit mentions, memberPubkeys, and participantPubkeys, so stale membership is propagated into outgoing event tags.

The current agent identity cannot repair the rows itself: buzz channels remove-member is correctly rejected because it is neither an elevated channel member nor the owner of the stale sibling agents. Buzz Desktop can remove current locally managed bots under the human identity, but its UI hides removal for the two stale owned profiles.

Operator repair requested for the affected tenant

Soft-remove only the two stale bot memberships from the affected DM and preserve all messages. The reporter can provide the exact channel UUID and two pubkeys through a private maintainer/operator channel.