fix(desktop): delete provider-backed instances before persona cascade

[jbforge]

Summary

Fixes #3771.

Deleting a persona whose managed-agent instances are provider-deployed always
failed. delete_persona
(desktop/src-tauri/src/commands/personas/mod.rs:113) takes only (id, app) —
there is no force parameter — and it hard-rejects the cascade when any target
is remote-deployed, via collect_remote_deployed
(mod.rs:81, matching backend != Local && backend_agent_id.is_some()):

persona {id} has provider-deployed agent instances (…); delete those agent instances first

Both persona-delete call sites went straight to deletePersona without
touching instances first, so they hit that rejection every time:

• desktop/src/features/agents/ui/usePersonaActions.ts — handleDelete
• desktop/src/features/profile/ui/UserProfilePanel.tsx — handleConfirmDeletePersona

The confirm dialog made it worse by promising the cascade unconditionally, so
the user saw a promise immediately followed by a refusal.

The fix

Delete the persona's instances first, so the cascade finds nothing left to
refuse. delete_managed_agent already has the escape hatch this needs —
force_remote_delete: Option<bool>
(desktop/src-tauri/src/commands/agents.rs:1276) — and the frontend already
wraps it in the right ritual: deleteManagedAgentWithRules sends !shutdown,
presents the orphan-warning confirm, and only then passes
forceRemoteDelete: true.

New deleteManagedAgentsForPersonaWithRules in
features/agents/lib/managedAgentControlActions.ts loops a persona's instances
through that per-agent function. Contract: stop the persona cascade at the
first cancelled or failed instance delete, so the persona itself is never
removed while instances remain. Instances already deleted when the abort fires
stay deleted — the cascade bounds the damage rather than unwinding it, and it
reports deletedCount so the caller can tell the user about that partial
state. Instances are deduplicated by normalized pubkey so a list carrying the
same instance twice cannot delete it twice.

Provider deployments are never force-deleted silently — every one goes through
the existing orphan-warning confirm, and declining it stops the whole cascade.

The delete dialog now calls out the provider-hosted instances in the cascade as
their own sentence rather than folding them into the relay-archival one. The
count is scoped to instances that are actually deployed
(backend.type === "provider" && backendAgentId), matching both the condition
the backend rejects on and the condition under which
deleteManagedAgentWithRules forces. Deleting removes the local management
record and its key, tombstones the agent's relay record, and archives its relay
identity — it does not tear down the provider deployment. There is no undeploy
operation today (commands/agents.rs:455), so the remote infrastructure keeps
running until it is removed at the provider, and the dialog now says so,
matching the orphan-warning confirm the same flow shows.

The backend guard is deliberately left alone. Its comment states the
invariant: the rejection is a runtime guard, and a compromised IPC caller must
not be able to orphan a live remote deployment. Adding a force flag to
delete_persona would weaken that for no gain, since the frontend can do the
instance deletion explicitly, behind the orphan-warning confirm, rather than
have the backend bypass its own invariant.

On the two loops

features/profile/ui/UserProfilePanelDeletion.ts has its own
persona-instance loop (deleteProfileManagedAgentsForPersona) and this PR
leaves it in place rather than sharing one implementation. Its extra work is
interleaved per instance — it removes each agent from its channels between
deletes — so sharing the loop would mean giving the generic helper a per-agent
callback parameter, and parameterizing a working delete path to save ~20 lines
seemed the worse trade. Both loops now carry a cross-reference comment naming
the other and the shared abort contract, so drift is visible to a reader.

Happy to consolidate them if maintainers would prefer that.

One deliberate asymmetry: the agents-side cascade does not remove instances
from their channels, while the profile variant does. That preserves the
pre-existing behaviour of the persona cascade — delete_persona only ever
tombstoned and archived — so this fix does not quietly widen what deleting a
persona does beyond making it succeed.

A note on the call signature

usePersonaActions.handleDelete now takes the instance-teardown function as a
required parameter, supplied by AgentsView, which already holds both the
persona and managed-agent hooks. That hook is also mounted app-wide by
RequestedAgentCreateDialogs, which never deletes anything, so wiring four new
queries into it to serve one button seemed wrong. Making the parameter required
rather than optional is deliberate: TypeScript now refuses a call that skips
instance teardown, instead of silently degrading back to the bug this PR fixes.

Tests

11 new, all passing.

Cascade (managedAgentControlActions.test.mjs):

• deletes every instance backed by the persona
• ignores instances backed by other personas
• deletes a duplicated pubkey only once
• stops at a declined orphan confirm — zero instances deleted
• stops at the first failed instance delete — later instances untouched
• a declined confirm does not undo earlier deletes — the aborting instance
  is deliberately not first, so the partial teardown is pinned rather than
  hidden by test ordering

The abort tests assert that instances after the stopping point are never
touched, and that deletedCount reports the ones already destroyed.

Dialog copy (PersonaDeleteDialog.test.mjs): singular and plural provider
disclosure, no provider claim when the count is zero, and parity with the
previous output for callers that don't pass the new argument.

Verified locally at the pushed commit: full desktop suite 3846 passed, 0
failed; just desktop-check exits 0 (biome, the file-size ratchet,
check:px-text, check:pubkey-truncation); just desktop-build
(tsc && vite build) succeeds; and desktop-tauri-check, desktop-tauri-test
and desktop-tauri-test-compiled-flags all pass. desktop-tauri-clippy fails
locally on macOS with three dead_code errors in
src-tauri/src/linux_media.rs — a file this PR does not touch, in a module
whose code is live on the Linux runner CI uses; this PR changes no Rust.

Not covered: there is no E2E test driving the rendered dialog against a
live provider deployment — the confirm path is exercised at the unit level with
a stubbed window.confirm, not through the real dialog. I also could not
verify against an actual provider-backed agent, so the claim that the cascade
now succeeds rests on the traced code path rather than on a reproduction. A
maintainer with a provider deployment to hand could confirm that end to end
quickly.

Related

• Fixes Provider-backed agent delete is routed through persona deletion and fails #3771.
• Closest existing PR: none found. Open PRs matching persona/delete/cascade
  terms are fix(persona): pack validate errors on skills the runtime would silently skip #3532 (persona pack skill validation) and fix(relay): retire the kind:30620 event on workflow delete (#2879) #3392 (relay workflow
  delete); neither touches this path.