A backup whose lock is lost stops with one line, not a stack trace (closes #184)

lockBackupDirectory now passes proper-lockfile an onCompromised that records
why the lock was lost, where the default threw from a timer and ended the
process. The backup checks its lock before each original and before it
writes failures.json, and fails with "lost the lock on DIR: REASON", which
quak backup prints through run as one line before exiting 1. Releasing a
lost lock leaves backup.lock alone, as it may be another backup's. The lock
of each directory is kept by path so that a backup run with lockHeld, as
quak backup runs it, finds the lock its caller took.

Model: opus-5-5

TODO.md

@@ -25,6 +25,15 @@ declares one.
 
 # Completed Steps
 
+- 2026-10-14: A backup whose lock is lost no longer dies with a stack trace
+  (issue 184). `lockBackupDirectory` gives proper-lockfile an `onCompromised`
+  that records why the lock was lost instead of throwing from its timer. The
+  backup then stops before it starts another original, and before it writes
+  `failures.json`, with `lost the lock on DIR: REASON`, which `quak backup`
+  prints as one line before it exits 1. Releasing a lost lock leaves
+  `backup.lock` alone. Tests in `test/cli/backup-end-to-end.test.ts` remove the
+  lock, or put another backup's in its place, while a download is held open.
+
 - 2026-10-14: An album or file quak cannot decrypt, or whose metadata is not
   JSON, no longer fails the refresh, so one bad record no longer stops
   `quak backup` from storing anything (issue 181). The refresh leaves it out, an