lib.backup() takes no new original once a worker has thrown, and checks its lock before going on

Once a worker has thrown, as one does when onProgress throws, or the
lock is lost, no worker takes another file, and the backup fails once
the originals under way are in place. Before, the other workers went on
through the rest of the account after a throw. Once the workers have
stopped, the backup checks its lock, so a lost lock no longer lets it
start the ML data fetch. The end-to-end test's comment now says the
backup has started all three originals when the lock is lost, not that
all three are still downloading.

Model: opus-5-5

test/cli/backup-end-to-end.test.ts

@@ -704,8 +704,8 @@ describe("a backup whose lock is lost", () => {
         }
     };
 
-    // The backup downloads up to five originals at once, so all three are
-    // under way when the lock is lost, and beach.jpg is stored. The backup
+    // The backup downloads up to five originals at once, so it has started
+    // all three when the lock is lost, and beach.jpg is stored. The backup
     // then stops before it fetches ML data. `quak backup` prints why as one
     // line, with no stack trace, and exits 1.
     it("stops quak backup before it fetches ML data when backup.lock is removed, and exits 1", async () => {