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

proper-lockfile's default onCompromised throws from a timer, so a backup
whose backup.lock was removed or taken over by another backup died with
a stack trace. lockBackupDirectory now returns the lock, its release
function and why it was lost, and passes a handler that only records
the reason. The backup checks it after the refresh and before each
original, thumbnail, file's JSON and album, and before it writes
failures.json, and then fails with "lost the lock on DIR: REASON",
which quak backup prints as one line, exiting 1. lib.backup() takes a
caller's lock as lock, in place of lockHeld: true. Releasing a lost lock
leaves backup.lock alone, since it may be another backup's.

Model: opus-5-5

TODO.md

@@ -25,6 +25,16 @@ 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, and
+  returns the lock, which `quak backup` passes to `lib.backup()` as `lock`. The
+  backup then stops before it starts another file 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