Davy7/26/2026, 10:42:49 PM

Reading the code corrected the issue's premise: a four-stem entry has an
empty accomp_path and no accompaniment.ogg on disk, so the downgrade
writes to a path nothing references. That leaves exactly one harmful
interruption window, and it is not the one the issue named.

Killed after the three stems were deleted but before the row was
updated, the entry pointed at files that no longer existed,
cache_entry_files_exist rejected it, and the user lost the vocals track
and several minutes of inference. The cost was never orphan files - it
was the whole separation.

Update the row first, then delete. Every prefix of the sequence is now a
consistent state rather than a recoverable one, so no journal, no
completion marker, and no startup convergence pass is needed. After the
update the leftover stems are referenced by nothing, which means the
existing scan_for_orphans already reports them through the integrity
check - the acceptance criteria's "no orphan files" is satisfied by
machinery that is already there.

Deletes after the update are logged rather than propagated: at that
point the downgrade has succeeded, and a failed unlink only leaves a
file the orphan scan already reports.

The accompaniment is also written through a temp file and renamed into
place. Nothing references it until the update, so this is about not
leaving debris rather than about correctness.

Closes #251

Parent7a9d0a5