[Bug] Second Desktop install creates duplicate agent identities, inflating channel membership

**Describe the bug**

When the same user installs Buzz Desktop on a second machine and joins the same community, the second install **creates its own set of default agents with fresh Nostr keypairs** and adds them all to the shared channel. The agents carry identical display names to the ones already there, so the channel roster shows each agent multiple times.

Our Welcome channel shows **8 members** for what is really **1 human + 3 agents**.

Single self-hosted community, fresh install — so this is not the cross-community collision in #2515.

**To Reproduce:**

1. Install Buzz Desktop on machine A, join a community, let the default agents (Fizz, Honey, Bumble) be created, and add them to a channel.
2. Install Buzz Desktop on machine B and sign in to the **same** community as the same user.
3. Open the same channel and run `buzz channels members --channel `.

**Expected behavior:**

An agent should have one identity and one channel membership per community, regardless of how many machines the owner installs on. A second install should register as an additional *runtime* for the existing agents rather than minting parallel same-named identities.

**Supporting Material**

Channel roster — `buzz channels members`, each pubkey resolved with `buzz users get`:

| Display name | Pubkey (first 8) | Role | Has ever posted |
|---|---|---|---|
| Serge | `bab2c2c9` | owner | yes |
| Fizz | `c9afa13c` | **member** | yes |
| Fizz | `614f28ba` | bot | yes |
| Fizz | `4ecf356f` | bot | yes |
| Honey | `c6cd9fae` | bot | yes |
| Honey | `c4125e50` | bot | **no** |
| Bumble | `8f0a2aa1` | bot | yes |
| Bumble | `90401f8c` | bot | **no** |

Six `bot` identities = 2 installs x 3 default agents. The seventh agent identity is an extra `Fizz` carrying role `member` rather than `bot`, which suggests a second creation path that disagrees on the role to assign.

Message counts with first/last post per pubkey, aggregated across all channels:

```
c9afa13c n=11 22:04:20 - 22:40:19 Fizz (role: member)
bab2c2c9 n=32 22:08:11 - 23:28:45 Serge (human)
614f28ba n= 7 22:52:44 - 23:18:30 Fizz \
c6cd9fae n= 1 23:12:28 Honey > install A
8f0a2aa1 n= 1 23:12:33 Bumble /
4ecf356f n= 5 23:19:50 - 23:27:07 Fizz \
c4125e50 n= 0 never posted Honey > install B
90401f8c n= 0 never posted Bumble /
```

Install B's first activity is at 23:19:50, ten seconds after the user first posted from the second machine. Install B's `Honey` and `Bumble` have **never posted** — they were never invoked on that machine. They exist purely because the install registered them.

That detail is what pins the cause to install time rather than session start: identities are created for agents that are never run.

**Environment**

- OS: macOS
- Buzz Desktop 0.4.23
- Self-hosted relay, single community, same user account on both machines

**Additional context**

*We may simply be holding this wrong — if creating per-machine agent identities is the intended design, we would appreciate knowing what the supported way to use one agent from two machines is.*

Impact as we experience it:

1. Member count inflates by the whole default roster per machine.
2. `@mention` targets are ambiguous — several live pubkeys share the name `Fizz`, and which one a mention reaches is not predictable.
3. Most duplicates are dead on arrival. An identity minted on machine B holds its key in machine B's keyring only, so it sits in the roster looking available while nothing can run it from elsewhere.
4. Roles are inconsistent across creation paths (`member` vs `bot`).

This appears consistent with the key-ownership model described in #2349, where a second machine "does not possess the agent's private key by design" — install B therefore has no way to adopt the existing agents and creates its own.

Possibly related, though none report roster duplication itself:

- #2349 — remote managed agents hidden/unmentionable on secondary devices (visibility half of the same multi-machine area)
- #2508 — remote agent missing from `@` mention autocomplete across machines
- #2423 — renaming/re-adding agents desynchronises identity (same symptom class, rename trigger)
- #2157 — additional running agents after restart (possibly the same underlying issue)
- #2515 — cross-community agent collision (same symptom, different axis; ruled out here)

Suggested directions:

1. Do not auto-create the default agent roster on an install that joins a community where those agents already exist.
2. Separate agent identity from agent runtime, so a new machine registers as another runtime for an existing identity.
3. Reconcile role assignment across creation paths.
4. Offer a way to prune duplicate memberships so affected channels can be cleaned up.
5. Disambiguate same-named identities in the mention picker while duplicates can exist.