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

lib.backup() ran its originals one at a time, so the content pool's five
slots, or the contentConcurrency of the pools a library was opened with,
went unused. The work for one original, its verify hashing included, is
now storeOriginal, and that many workers take files from one iterator
over the backup's files, so no more originals than the limit are open at
once. BackupLibrary gains contentConcurrency, which the library sets from
its content pool. The README's "Request pools" says so. The tests of a
backup whose lock is lost now expect all three originals downloaded,
since all three are under way at once.

Model: opus-5-5

test/cli/backup-concurrency.test.ts

@@ -208,7 +208,8 @@ const holdingServer = (failing?: number) => {
 // Let the held downloads go one at a time, the first to arrive first, each
 // once `limit` of them wait, or all the downloads still to come when there
 // are fewer. Each of the eight photos is downloaded once. With a backup that
-// downloads fewer than `limit` at once, this fails waiting for them.
+// downloads fewer than `limit` at once, this fails waiting for them. Each wait
+// allows five seconds, for a loaded machine's disk to sync the files written.
 const releaseOneAtATime = async (
     held: { release: () => void }[],
     limit: number,
@@ -216,7 +217,7 @@ const releaseOneAtATime = async (
     for (let left = PHOTO_IDS.length; left > 0; left--) {
         await vi.waitFor(
             () => expect(held).toHaveLength(Math.min(limit, left)),
-            { interval: 5 },
+            { interval: 5, timeout: 5000 },
         );
         held.shift()!.release();
     }
@@ -340,6 +341,7 @@ describe("lib.backup()", () => {
             });
             await vi.waitFor(() => expect(holding.held).toHaveLength(5), {
                 interval: 5,
+                timeout: 5000,
             });
             expect(mismatches()).toHaveLength(5);