Bug: owner-reviewed agent drafts can leave orphan profiles without runnable records

[marisgoerner-cell]

Describe the bug

On Buzz Desktop 0.5.5 for macOS, a batch of owner-reviewed draft-create forms appeared to save successfully, but the resulting identities are orphaned: their kind:0 profiles and bot channel memberships exist on the relay, while no local managed-agent record, retained kind:30177 head, or durable agent key exists. They are absent from the Agents view, unavailable in Desktop mention autocomplete, and cannot run.

This is distinct from the cross-device mention-only case in #3277: the affected identities are missing from the same Desktop that reviewed and saved the forms, and there is no host runtime left to invoke.

Observed sequence

1. Agents sent owner-reviewed draft-create requests through the supported Buzz CLI flow.
2. The owner reviewed and saved eleven create forms in Desktop 0.5.5.
3. Follow-up draft-update forms were also reviewed and saved for those names.
4. After restart, all eleven were absent from the Agents view and mention autocomplete.

The create/update requests were sent close together, but the owner reviewed the forms individually.

Evidence from the affected installation

• App version/build: 0.5.5 / 0.5.5, Apple Silicon macOS.
• All eleven active pubkeys have resolving kind:0 profiles and are current bot members of the channel.
• Six older duplicate pubkeys are separately archived; the active eleven are not archived.
• agents/managed-agents.json contains 17 records, all belonging to the pre-existing seven definitions/instances and older built-in duplicates. None of the eleven pubkeys or names occurs anywhere under the app data directory.
• The active scoped retention databases contain kind:30177 heads only for pre-existing agents (10 and 14 heads respectively); none contains any of the eleven pubkeys.
• The macOS buzz-desktop keychain blob exists, but its modification time predates the eleven saves. No key material for those pubkeys was durably added.
• None of the eleven pubkeys has authored a message in the affected channel.
• Re-publishing channel membership events does not help, as expected: membership cannot reconstruct runnable private configuration.

Expected behavior

Saving an owner-reviewed create form must be atomic from the user's point of view:

1. Either the private key/config, local record, public managed-agent projection/profile, and requested channel attachment all commit successfully; or
2. the save fails visibly and compensates any already-published public profile/membership so no orphan identity remains.

The Desktop should not dismiss the form or report success until durable local/private state is verified. On startup, an owner-authored public profile with no runnable configuration should be surfaced as an explicit recovery/error state rather than silently omitted.

Relationship to existing work

• Managed agents are only mentionable from the machine that runs them #3277 / fix(desktop): allow shared agent mentions #4913 cover mentionability of remotely hosted agents. That does not restore a missing host runtime.
• Relay-primary private managed-agent config #4999 adds encrypted relay-primary private managed-agent configuration and fresh-device materialization. It appears to be the right prevention/recovery foundation for future creates, but this 0.5.5 incident has no private config event to recover. Please add a create-transaction regression covering interruption or concurrent reviewed drafts, and define upgrade/recovery UX for pre-30179 orphan profiles.

Suggested regression invariant

After any create command returns success, assert all of the following for the same pubkey:

• the key store can read the generated nsec;
• managed-agents.json (or the authoritative successor store) contains the runnable record;
• retained public and private config heads exist as applicable;
• relay profile publication and channel attachment completed;
• a fresh list/refetch displays exactly one agent and can resolve its mention target.

Inject a failure after each persistence/publication phase and assert either full recovery on restart or complete compensation, never a profile-only orphan.