quak backup works on up to the content pool's limit of originals at once (closes #182)

The backup awaited each original before starting the next, so it used
one of the content pool's five slots. lib.backup(), and so quak backup,
now runs as many workers as the content pool's limit (5 by default, or
the contentConcurrency of the pools the library was opened with), each
taking the next file from one shared list, so the limit covers the
--verify hashing too. Once a worker has thrown or the lock is lost, no
worker takes another file; the backup waits for the files under way and
checks its lock before the ML data fetch. runBackup rejects a
contentConcurrency that is not a positive integer before it takes the
lock. Failed files are listed in the order they failed.

Model: opus-5-5

TODO.md

@@ -17,18 +17,26 @@ pre-1.0
 
 # Next Step
 
-`quak backup` downloading one original at a time,
-https://git.eeqj.de/sneak/quak/issues/182, is fixed in
-https://git.eeqj.de/sneak/quak/pulls/192, which waits on review. No other
-implementation work is open. The check of quak against a live Ente account,
-https://git.eeqj.de/sneak/quak/issues/187, needs an account only sneak has, so
-it waits on him.
+None: no implementation work is open. The check of quak against a live Ente
+account, https://git.eeqj.de/sneak/quak/issues/187, needs an account only sneak
+has, so it waits on him.
 
 Tagging and releases are decided by sneak alone, and happen only when he
 declares one.
 
 # Completed Steps
 
+- 2026-10-14: `lib.backup()`, and so `quak backup`, works on up to the content
+  pool's limit of originals at once, 5 by default, instead of one at a time
+  (issue 182). That many workers take files from one shared list, each doing all
+  the work for one original, its `--verify` hashing included, so no more
+  originals than that are open at once. `BackupLibrary` says the limit as
+  `contentConcurrency`. A test holds each download at the fake Ente server to
+  count those in flight. Once a worker has thrown, as one does when `onProgress`
+  throws, or the lock is lost, no worker takes another file; the backup fails
+  once the originals under way are in place, and a lost lock stops it before it
+  fetches ML data.
+
 - 2026-10-14: Next Step said the cache design, issue 36, waits on sneak's
   review, though that issue closed on 2026-10-03 (issue 194). It now names the
   issues open on the tracker.