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/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.