Fix nine review findings in the documents and help text

- snapshot verify and snapshot restore also list the destination for a
  snapshot ID that is not in the local index: README, REPOSTRUCTURE,
  ARCHITECTURE, DATAMODEL and the two commands' help.
- prune on a separate machine deletes only unused data and does not
  remove old snapshots.
- The --quiet usage string names everything the flag leaves out.
- A warning written as a log record stays on stderr.
- config set on a config that does not load refuses three things.
- No test is held back by a build tag.
- A plain docker build . adds no -dirty.
- The backup's order of work records directories.
- TODO.md says what parallel downloads would speed up and names
  restorePlan and restoreSweeper.

Model: fable-5-1

docs/ARCHITECTURE.md

@@ -291,10 +291,11 @@ therefore marks a backup that did not finish.
 - With `--verify`, `verifyRestoredFiles` reads each restored regular file and
   checks its chunk hashes.
 
-Given a snapshot ID, the restore does not read the local index. Given a remote
-key, it reads the local index only to check the destination marker. It does not
-read the manifest. It finds each file's chunks and blobs through the downloaded
-database.
+Given a snapshot ID, the restore looks it up in the local index. When it is not
+there, the restore checks the destination marker and lists the snapshot's
+directory. Given a remote key, it reads the local index only to check the
+destination marker. It does not read the manifest. It finds each file's chunks
+and blobs through the downloaded database.
 
 ### Checks on the downloaded database
 

docs/DATAMODEL.md

@@ -299,6 +299,7 @@ A backup works on the tables in this order:
 - It walks each path. It compares each regular file and symlink with its row in
   `files`.
 - It links each unchanged file to the snapshot in `snapshot_files`.
+- It writes a `files` row and a `snapshot_files` row for each directory.
 - It records each mount point in `snapshot_mount_points`.
 - It reads each changed regular file and stores it. See below. A changed symlink
   is recorded without being read.
@@ -362,9 +363,9 @@ still be in the `-wal` file beside it.
 
 ### Restore
 
-A restore reads no file, chunk or blob rows from the local index. Given a remote
-key, it reads `snapshots` and `local_meta` there to check the destination
-marker.
+A restore reads no file, chunk or blob rows from the local index. It reads
+`snapshots` and `local_meta` there, to look up a snapshot ID and to check the
+destination marker.
 
 - It downloads and decrypts `db.zst.age` into a temporary directory.
 - It opens that file read-only. It applies no migration to it.

docs/REPOSTRUCTURE.md

@@ -59,7 +59,8 @@ not exist, commands treat the destination as not present:
     - `prune`
     - `snapshot purge`
     - `remote nuke`
-    - `snapshot verify` and `snapshot restore`, when given a remote key
+    - `snapshot verify` and `snapshot restore`, when given a remote key, or a
+      snapshot ID that is not in the local index
 - `snapshot list` shows the local index alone.
 - `snapshot remove` deletes nothing at the destination.
 
@@ -334,12 +335,14 @@ An upload there looks up the object it replaces and deletes it. It stops when
 the look-up is refused.
 
 `snapshot verify` and `snapshot restore` list only when they are given a remote
-key. `snapshot remove --local-only` does not reach the destination.
+key, or a snapshot ID that is not in the local index.
+`snapshot remove --local-only` does not reach the destination.
 `snapshot remove --dry-run` deletes nothing.
 
 `snapshot create --prune` runs a prune on the backed-up machine. That machine
 then holds credentials that can delete its own backups. To keep it to write-only
-credentials, run `prune` from a separate, trusted machine.
+credentials, run `prune` from a separate, trusted machine. `prune` there deletes
+only data that no snapshot uses. It does not remove old snapshots.
 
 ### New recipients cannot read old data
 

docs/TODO.md

@@ -41,10 +41,11 @@ Work planned after 1.0, loosely ordered by priority.
 
 - **Parallel blob downloads during restore.** A restore downloads one blob at a
   time now. With a fast S3 endpoint and a multi-core machine, restore speed is
-  bound by the fetch, decryption and decompression of each blob. Running several
-  of those in parallel against the disk cache would close most of the remaining
-  gap. This needs to interact correctly with the locality planner and the
-  sweeper.
+  bound by the fetch, decryption and decompression of each blob. Fetching,
+  decrypting and decompressing several blobs at once would make such a restore
+  faster. The change must work with `restorePlan`, which orders the files, and
+  with `restoreSweeper`, which deletes a cached blob once no remaining file
+  needs it.
 - **Bandwidth limiting (`--bwlimit`).** For both upload and download. It is
   useful for backing up over a shared link. It is tricky to make work correctly
   with parallel downloads.