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

README.md

@@ -779,9 +779,9 @@ A running backup loses its lock when someone removes `backup.lock`, or when
 another backup takes it over because the running one left it untouched for 10
 seconds, as a stopped or stalled process does. The backup finds this out the
 next time it goes to touch the lock, which it does every 5 seconds, and then
-stops before it starts another file. The original it is downloading at that
-moment is still stored. It leaves `failures.json` and `backup.lock` as they are,
-since another backup may be using them. `quak backup` prints
+stops before it starts another file. The originals it is downloading at that
+moment are still stored. It leaves `failures.json` and `backup.lock` as they
+are, since another backup may be using them. `quak backup` prints
 `quak: lost the lock on <dir>: <reason>` as one line and exits 1, and
 `lib.backup()` rejects with `lost the lock on <dir>: <reason>`.