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

TODO.md

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