Built-in personas get a fresh keypair per community; custom agents reuse one identity across communities

# Built-in personas get a fresh keypair per community; custom agents reuse one identity across communities

## Summary

On a **single Desktop installation**, Buzz applies two different identity policies at once:

- **Built-in Welcome Team personas** (Fizz, Honey, Bumble) are minted with a **new keypair per community**.
- **Custom agents** keep **one identity across every community** they run in.

The result is duplicate same-named identities on the roster and ambiguous `@mentions`, from nothing more than joining a second community and leaving again.

This is distinct from the issues it resembles:

- **#2648** attributes duplicate identities to a *second install*. This is one install, one machine.
- **#2515** covers agents from different communities *colliding in a channel* — that is a downstream symptom, not the minting rule.
- **#4099** is adjacent (no community-scoped tier) but is about credentials, not identity.

Nobody appears to have written up the inconsistency itself.

## Environment

- Buzz Desktop **0.5.3**, macOS (Apple Silicon), single installation
- Community A: a self-hosted relay (redacted)
- Community B: `wss://vibecoding.communities.buzz.xyz` — joined, then left

## Evidence

Agent harness logs are named `__.log`, which makes the
per-community split directly observable without any instrumentation:

```
sha256("wss://vibecoding.communities.buzz.xyz") = c73ac6502b3fa5f1…
```

Same install, same `managed-agents.json`, both communities:

| agent | community A | community B | policy |
|---|---|---|---|
| **Bumble** (built-in) | `4a8f04bb…` | `8c11c941…` | **new key per community** |
| **Honey** (built-in) | `68c327da…` | `b4d37005…` | **new key per community** |
| **Fizz** (built-in) | `c0696554…` | `025aae9e…` | **new key per community** |
| claude (custom) | `97935ab5…` | `97935ab5…` | one identity |
| Terra (custom) | `ca941694…` | `ca941694…` | one identity |
| sonnet (custom) | `22d8d9c2…` | `22d8d9c2…` | one identity |

## Timeline

Instance `created_at` values from `managed-agents.json` show the mint is machine-paced, not
user-initiated — three agents in **two seconds**, at the moment community B was joined:

```
2026-07-28 03:23:52 Fizz c0696554… ← community A, first run
2026-07-28 03:23:55 Honey 68c327da…
2026-07-28 03:23:57 Bumble 4a8f04bb…
2026-07-28 04:24:30 claude 97935ab5… ← custom agents, created individually,
2026-07-28 05:14:29 Terra ca941694… minutes to hours apart
2026-07-28 11:47:06 sonnet 22d8d9c2…
2026-07-31 03:33:20 Fizz 025aae9e… ← joined community B
2026-07-31 03:33:21 Honey b4d37005… three fresh keypairs, 2 seconds
2026-07-31 03:33:21 Bumble 8c11c941…
```

All three new keys have harness logs, so they are live identities, not inert records.

## Leaving does not clean up

Community B was left afterwards. The three identities it caused to be minted remain in the
local store, and their channel memberships and kind:0 profiles remain published on that relay.
Nothing in the leave path retracts them.

That matters because those artifacts are unusually hard to remove afterwards, as #2973 notes:

- a channel membership can only be removed by that **channel's owner**;
- a kind:0 profile can only be replaced by the key that signed it — and once the agent record
is deleted locally, that key is gone, so the profile is **permanently unretractable**.

So a join/leave cycle can leave same-named identities on a relay that literally no one can
clean up.

## Impact

- Duplicate rows in channel rosters for one logical agent.
- `@Name` becomes ambiguous. Mention resolution stops before sending on an ambiguous name
(correctly — it should not guess), so the mention fails and no agent wakes.
- The stranded identity is offered by name lookup indefinitely.

## The actual question

Which policy is intended?

Both are defensible on their own. One identity per agent is simple and keeps a stable pubkey,
but correlates the same agent across communities. A key per community avoids that correlation
but produces exactly these duplicates. **Having both at once, split by whether the agent
happens to be built-in, looks unintended** — and whichever way it is resolved, the leave path
needs to deal with identities the join path created.

Start by inspecting managed-agents.json and tracing the community join and leave paths that create and retain built-in and custom agent identities. Compare keypair creation with the published channel memberships and kind:0 profiles described in the report. Done means the project has a decided, consistent identity policy and the leave path handles identities created during joining.

Written by the indexing model from the issue text.