Desktop batch deploy/restore mints duplicate keyed agent identities in the same local store

## Summary

Buzz Desktop 0.5.17 created five new managed-agent identities in one batch for five definitions that already had keyed instances in the same local `managed-agents.json`. The new identities have the same display names, persona IDs, team IDs, prompts/models, and owner as the existing agents, but fresh pubkeys.

The duplicate cards are hidden in Desktop's Agents screen because same-name records collapse to one visible card. The generated nest `AGENTS.md` renders all keyed records, exposing 13 rows for 8 names.

## Observed evidence

Environment:

- Buzz Desktop 0.5.17
- macOS
- One local app-data store
- Hosted single community

Store state:

- 13 keyed `ManagedAgentRecord` entries
- 8 unique display names
- Five names have two distinct pubkeys
- The older identity for each name is a current channel member
- The newer identity for each name has no channel membership and has authored no messages

All five duplicates were minted within four seconds on 2026-08-18:

| Name | Original created | Duplicate created | Definition/team relationship |
|---|---:|---:|---|
| Karoo (Research) | Aug 17 | 10:55:41Z | same persona ID and custom team ID |
| Ace (Content) | Aug 17 | 10:55:42Z | same persona ID and custom team ID |
| Luffy (COO) | Aug 17 | 10:55:42Z | same builtin persona and welcome team |
| Zoro (Store/Ads) | Aug 17 | 10:55:43Z | same builtin persona and welcome team |
| Sanji (FA) | Aug 17 | 10:55:45Z | same persona ID; no team ID on either record |

Each duplicate was immediately started. Per-agent logs begin at its creation timestamp and show successful harness initialization and relay connection. They later exited cleanly. This rules out a passive display-only duplication.

At observation time:

- Desktop Agents screen displayed 8 cards.
- `managed-agents.json` contained 13 distinct keyed records.
- nest `AGENTS.md` displayed 13 rows.
- `buzz channels members` across all current channels found only the 8 originals.
- `buzz messages search --author ` returned no messages for all five duplicates.
- No duplicate had a running PID.

## Expected behavior

Starting agents, deploying a team, restoring on launch, applying a snapshot, or reconciling definitions must reuse an existing keyed instance for the same owner + definition/team relationship. Identity creation must be an explicit owner action and must not silently mint a second keypair for an already-instantiated definition.

The Agents screen should also not hide multiple keyed records behind one same-name card; owners need pubkey-level visibility and a safe archive/remove path.

## Actual behavior

A single local store accumulated five new keyed instances in one batch. The duplicates started successfully but never joined channels or sent messages. Desktop showed only one card per name, making the extra identities unmanageable through the UI.

## Safety impact

- Silent creation of signing identities
- Unnecessary compute from automatic startup
- Ambiguous `@mention` resolution if duplicates later join a channel
- Hidden local identities that cannot be removed through Desktop
- Managed nest context reports an inflated roster

## Suggested investigation

The shared timestamp and immediate startup suggest a batch deploy/restore/reconcile path rather than five independent user creates. Audit all paths that materialize `ManagedAgentRecord` instances from persona/team definitions:

1. Before key generation, resolve an existing keyed record by stable definition identity (`persona_id`/slug plus owner/community), not display name alone.
2. Make create-and-save atomic under a single lock to prevent concurrent batch tasks from each observing “missing” and minting.
3. Add a store invariant/test: at most one locally owned keyed instance per stable definition unless the user explicitly requests another instance.
4. Render duplicate keyed records distinctly in the Agents UI with pubkey prefixes and a recoverable removal/archive flow.
5. Log the creation reason/path for every minted identity.

## Related issues

- #2973 — stale duplicate agents cannot be removed from Desktop
- #2648 — second Desktop install creates duplicate identities
- #5868 — dangling team/persona references silently mint replacements
- #3440 — deleting relay-synced definitions can orphan live agents

This report differs in that the originals and duplicates coexist in the **same local app-data store**, share the same definition/team relationships, and the duplicates were created and auto-started as one batch.