fix(desktop): cascade persona deletes and restart agents on global config save

[wpfleger96]

Fixes two agent-lifecycle issues from fresh-install feedback:

• Deleting an agent definition now deletes its instances — atomically. delete_persona previously nullified persona_id on linked managed agents, so deleted agents reappeared under "Custom agents" (one surface — UserProfilePanel — papered over this with a frontend-side cascade; the nav path didn't). The backend now cascades in three phases under the store lock: stage (every fallible load/lock — persona, teams, agents, process sync — happens up front with zero destructive writes, plus a pre-flight that refuses the cascade while any target is a provider-deployed agent, mirroring delete_managed_agent's force_remote_delete guard), stop (best-effort stop of running instances, with the process lock taken per agent so it is not held across the stop poll cycle), then commit (agent-store save → persona save → keychain deletes → kind:30177 tombstones — disk-authoritative writes strictly before side effects). A failure at any disk write leaves state intact and the command retryable; the injectable commit_cascade_agents seam is unit-tested with a failing save to prove it. The confirm dialog says "Also deletes N agent instance(s)." and the redundant frontend cascade is removed. The builtin-deactivation path keeps its own instance cleanup — builtins are deactivated rather than deleted, so the backend cascade doesn't apply there.
• Saving global agent config restarts affected running agents — and reports failures. Previously only setup-listener agents whose readiness flipped NotReady→Ready were respawned; running agents silently kept their stale env (env is baked at spawn time, so a restart is the only honest delivery mechanism). set_global_agent_config now restarts every running local agent whose effective env changed under the new config — including Ready→NotReady (credential removed), which restarts into setup-listener mode via the normal spawn path. The command returns GlobalAgentConfigSaveResult { config, restarted_count, failed_restart_count }; the settings card reports "Saved. Restarted N agent(s)." and appends "M failed to restart — check the Agents tab." when a stop succeeded but the respawn failed. The card also snapshots the submitted config so an edit made during the save round-trip is never clobbered by the resolving response — the newer value survives and the card stays dirty for a follow-up save.

Both behaviors are covered by a Playwright screenshot spec (agent-lifecycle-feedback.spec.ts) driving the cascade confirm dialog (plural, singular, and zero-instance copy), all three save outcomes, and the mid-save edit race through configurable bridge mocks.

[wesbillman]

Blocking on making the cascade failure-atomic/recoverable.

delete_persona saves the persona removal and queues its tombstone before loading/locking the linked-agent cascade. It then deletes linked keys and queues agent tombstones before the final filtered save_managed_agents. If any later load, process-lock, or agent-store save fails, the command returns an error after irreversible partial deletion: linked records can remain without their persona/key, and retrying through the normal persona-delete path is no longer possible because the persona is already gone.

Please stage and validate all cascade state before committing destructive changes, then order disk-authoritative writes and side effects so an error remains safely retryable. Please also cover an injected failure after persona discovery / before the final agent save; the current helper tests only verify pubkey filtering, not the partial-failure behavior.

[wpfleger96]

🤖 hey @wesbillman, thanks for the careful review — the cascade ordering was genuinely unsafe. I reworked delete_persona into three phases under the store lock:

1. stage — every fallible load/lock (personas, teams, agents, process sync) happens up front with zero destructive writes, plus a new pre-flight that refuses the cascade while any target is a provider-deployed agent (mirrors delete_managed_agent's force_remote_delete guard — turns out nothing in create_managed_agent forbids a persona-linked provider agent, so this couldn't be assumed away)
2. stop — best-effort stops of running instances, process lock taken per agent
3. commit — save_managed_agents → save_personas → keychain deletes → tombstones, so disk-authoritative writes land strictly before any side effect

If the agent-store save fails, nothing was destroyed and a retry re-runs the full cascade; if the persona save fails, the persona survives and a retry finds an empty cascade and completes cleanly. Keys and tombstones are only touched after their records leave disk.

On the injected-failure coverage: phase 3 goes through an injectable commit_cascade_agents(agents, cascade, save) seam (there's no AppHandle mock harness in the crate, so the seam is the testable substitute) — failing_save_is_retry_safe in delete_cascade_tests.rs injects a failing save and verifies it propagates before any keyring/tombstone side effect. There's also a remote_deployed_cascade_target_blocks_delete test for the new pre-flight.

I think this covers both points, but happy to iterate if you'd order things differently.

[wpfleger96]

🤖 Updated lifecycle screenshots from the current branch:

Delete cascade confirm (plural)

Delete cascade confirm (singular)

Save with restarts

Save with no restarts

Save with a failed restart

A stop succeeded but the respawn failed — the card points at the Agents tab.