lib.backup() starts no further original once its lock is lost

Issue 184 checked the backup's lock before each original, in the loop
this branch replaces with several workers. Each worker now checks the
lock before it takes the next file, so once the lock is lost no further
original starts; the originals under way are finished, and the backup
rejects once every worker has stopped. The README says the originals
under way, not the one, are still stored.

Model: opus-5-5

TODO.md

@@ -32,7 +32,8 @@ declares one.
   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.
+  count those in flight. Each worker checks the backup's lock before it takes
+  the next file, so once the lock is lost no further original starts.
 
 - 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