A Take deleted from the Device by hand leaves its stand-in listed on the Drive's Take.json #947

Summary

Deleting a kept Drive only Take from this iPhone (Delete from iPhone) removes the Device's stand-in, but the Drive's Take.json keeps listing it under standIns. A move that finishes the same Take, or the recovery after a crash during the delete, clears that listing. So the Drive's file differs depending on how the Device's stand-in went away.

Why it matters

Nothing the operator sees is wrong today. But #879 treats it as an invariant that the Drive names a stand-in only while the Device holds it, and a stale entry is the kind of thing that breaks a later change quietly.

Done when

• Decided: either Release clears the listing on the Drive (after the delete, or before it with a way back), or the listing is allowed to go stale and the readers are written to ignore a stand-in the Device no longer has.
• A test for whichever is chosen: a Release of a kept stand-in Take, then the Drive's Take.json read.
• If Release starts writing the Drive, the released test ("the Drive's Take is not touched") and its reasoning are updated, because that is what pins today's behavior.

Details

Found while writing the tests for #890 (the crash at the set-aside step of a delete from the Device, #946). With a kept stand-in Take of one channel (stand-in 0 to 3000, Drive holds 4800 frames), after DeviceTakeRelease.run returns released the Drive's Take.json still has standIns: [start 0, end 3000]. After a crash at .setAside and MoveRecovery.run, the same Take ends with standIns == nil on the Drive.

Release not writing the Drive is deliberate: released in DeviceTakeReleaseTests pins "the Drive's Take is byte for byte as it was", and a Drive write after the delete has nothing to undo if it fails.

Not user-visible today. Readers of the Drive-side standIns that were checked:

• Show report (ShowReport): uses it for held ranges only when no whole Stem exists; the Drive has whole Stems, so it is ignored.
• Reaper project export (ShowProject): takes the larger of the Stem length and the stand-in's end; the stand-in's end is never past the Drive's Stem.
• AbandonedCopyRecovery: the same larger-of rule.
• ShowList, TakeMover, StandInMove: read only the Device's Take.json, and the Device's folder is gone.
• CutOffTake.finish: falls back to the Drive's file when the Device has none, and sees the stale entry, but only to set lastTakeWasDriveOnly, which is true anyway.
• TakeRepair: acts only on a live session with a Device folder.

Verified on main 2026-10-22 at 960b1e7