fix(start-core): make install rollback crash-recoverable, and snapshot a stopped service

[helix-nine]

@dr-bonez — this is the rollback hardening from the Nextcloud data-loss investigation, with the ordering you asked for.

Why

The rollback is the only thing in the stack that deletes a populated volume during an update, and it was doing it non-atomically:

btrfs::delete_tree(&dst).await?;              // whole package volume root
crate::util::io::rename(&backup, &dst).await?;

Interrupt between those two and the service has neither copy. Worse, it doesn't look interrupted: handle_installed and Bind::pre_mount both recreate a missing data/<vol> as an empty dir, so the next boot sees a live root that exists, and the sweep's "backup with no live volume" test — the one recovery we had — doesn't fire. The stranded backup then gets deleted by the next attempt's snapshot, whose first act was "remove any stale backup". That last step is where the data actually goes.

What changed

The protocol now lives on one type, volume::InstallBackup, which owns the four paths (live, backup, backup-tmp, restore-old) and the operations over them:

• Restore is a two-rename swap: live → .restore-old, backup → live, drop the aside tree. .restore-old marks a restore in flight and survives the empty-skeleton recreation, so resolve_pending() maps every interruption point to exactly one resolution — including refusing to pick a winner when the live tree and the backup both hold real files. It runs from ensure_volume_root (the funnel every path goes through before trusting the live root), the snapshot, the boot sweep, and remove, which refuses to discard a backup while a restore is in flight.
• The snapshot stages at .install-backup-tmp and swaps, so the previous rollback point is dropped only once its replacement exists.
• A failed rollback notifies and propagates instead of being log_err'd into looking like a clean revert — after which the success path deleted the rollback point it still needed.
• A failed first-time install over pre-existing data keeps that data: the Installing arm ran cleanup(soft=false) — an unconditional whole-root delete — before checking for a backup. That arm is what a 0.3.x→0.4.0 package conversion runs under.
• The boot sweep resolves every pending restore in a first pass, so readdir order can't reap a backup a .restore-old marker still needs.
• ServiceRef::quiesce stops the main chain before the snapshot, leaving uninit to uninstall.

On the ordering

Snapshot-before-uninit was already true, and a CoW snapshot is atomic, so uninit's writes can't reach it. The new thing is the quiesce: nothing is writing to the tree a later rollback will rename or delete, and the rollback point is the state the user had when they pressed update. quiesce goes through the actor, which owns run state: it marks the desired status Updating (a new DesiredStatus variant, modeled on BackingUp) and waits for the actor to perform the stop. init() maps Updating back to Running, so the replacement service starts after a successful update — and the old one starts again if a crash lands mid-update.

Tests

10 unit tests over the state machine, run on a plain tmpdir — no btrfs, no root — across {live present / skeleton / absent} × {backup} × {restore-old}. cargo test -p start-core --lib: 561 passed.

Deliberately not in this PR

• The version bump. Added the ## [0.4.0.2] CHANGELOG heading; left the manifest half alone — say the word and I'll add it as a second commit.
• cancel_install is an abandon, not a cancel: the migration keeps running while a detached load(Undo) does the renames. Two writers, one volume tree, no barrier. Wants its own change.
• Durability ordering: the Updating → Installed(old) flip still commits before the renames. The on-disk marker makes that recoverable, but a rollback: bool on UpdatingState would also stop a crash mid-rollback from resuming a cancelled update.
• Dependency mounts can recreate a volume root while a restore is pending (Bind::pre_mount); snapshot_subvolume is non-recursive, so a nested subvolume lands in a backup as an empty dir.

Test plan

1. cargo test -p start-core --lib.
2. On a VM: update a running service, confirm it comes back running and healthy.
3. Cancel an update mid-init; confirm the service returns to its old version with its data, and the backup is gone afterwards.
4. Simulate the incident: kill -9 startd between the two renames (or drop a .restore-old by hand), reboot, and confirm the boot sweep finishes the restore rather than starting on empty data.
5. Confirm a failed rollback surfaces as an error notification and leaves the package unloaded.

[helix-nine]

Cleaned up per review:

• Comments cut to one-liners per CONTRIBUTING; doc comments kept only where the why is non-obvious.
• The restore protocol now lives on a single volume::InstallBackup type that owns the four paths (live/backup/backup_tmp/restore_old, built with with_extension) and the operations over them (snapshot/restore/resolve_pending/remove/exists) — replaces the free functions + sibling_of + the _in test variants, which also made the snapshot's three identical degrade-and-warn arms collapsible into one.
• Quiesce timeout dropped; quiesce is now infallible and just stops.

Behavior is unchanged from the reviewed version apart from the timeout removal; 561 lib tests pass. (Ignore the double force-push — the first grabbed a stale local branch by name; head is d0ed86c.)

[helix-nine]

Reworked the quiesce to go through the actor per your comment — no more direct persistent_container.stop().

DesiredStatus gains an Updating variant, modeled on BackingUp:

• quiesce marks the status Updating (only if it was Running/Restarting) and waits for the actor to report started: None. The actor's existing stop arm performs the stop, so run state stays actor-owned.
• init() maps Updating back to Running (same as Restarting), which covers both exits: the replacement service starts after a successful update, and a crash mid-update boots the rolled-back old version into Running rather than leaving it stopped.
• A service that was Stopped stays Stopped throughout — quiesce leaves the status alone and its wait is immediately satisfied.
• The UI needed no changes: during an update stateInfo.state is already updating, and Updating never survives into the Installed state. Regenerated DesiredStatus.ts is the only binding change.

561 lib tests pass, fmt clean.