Format the rewritten documents with prettier

Re-wraps README.md, docs/ARCHITECTURE.md, docs/DATAMODEL.md,
docs/REPOSTRUCTURE.md and the roadmap in docs/TODO.md with `make fmt`,
which now runs prettier on Markdown. Only line wrapping changes; the
words are those that passed review at 4da102c.

Model: fable-5-1

docs/TODO.md

@@ -23,60 +23,58 @@ Work planned after 1.0, loosely ordered by priority.
 
 ## Correctness and operability
 
-- **Outside security audit.** Before 1.0 the encryption and
-  blob-generation code was reviewed. Every bug the review found was
-  fixed. The risks it accepted are listed in
-  [Accepted risks](docs/REPOSTRUCTURE.md#accepted-risks). No outside
+- **Outside security audit.** Before 1.0 the encryption and blob-generation code
+  was reviewed. Every bug the review found was fixed. The risks it accepted are
+  listed in [Accepted risks](docs/REPOSTRUCTURE.md#accepted-risks). No outside
   audit has been done. age, zstd and content-defined chunking are mostly
   off-the-shelf pieces. The code that joins them needs an outside read:
     - key handling
     - recipient parsing
     - manifest trust boundary
     - restore-time identity validation
-- **Verify restored content end-to-end in CI.** The current integration
-  test does this for a small synthetic snapshot but not at scale. A
-  nightly job against a multi-GB representative snapshot would catch
-  silent regressions in the chunker, packer, or restore planner.
+- **Verify restored content end-to-end in CI.** The current integration test
+  does this for a small synthetic snapshot but not at scale. A nightly job
+  against a multi-GB representative snapshot would catch silent regressions in
+  the chunker, packer, or restore planner.
 
 ## Performance
 
-- **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.
-- **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.
-- **Restart of interrupted restore.** Today a restore can be started
-  again, and it then overwrites the partial output. It does not resume
-  from where it stopped, and it does not skip files that are already
-  present. A `--resume` mode that checks targets before fetching blobs
-  would matter for very large restores.
-- **Daemon mode.** A long-running mode that watches for file changes,
-  so that frequent backups, such as hourly ones, skip the full scan. It
-  adds little for the usual backups from cron every 12 to 36 hours. See
+- **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.
+- **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.
+- **Restart of interrupted restore.** Today a restore can be started again, and
+  it then overwrites the partial output. It does not resume from where it
+  stopped, and it does not skip files that are already present. A `--resume`
+  mode that checks targets before fetching blobs would matter for very large
+  restores.
+- **Daemon mode.** A long-running mode that watches for file changes, so that
+  frequent backups, such as hourly ones, skip the full scan. It adds little for
+  the usual backups from cron every 12 to 36 hours. See
   [issue #204](https://git.eeqj.de/sneak/vaultik/issues/204).
 
 ## Usability
 
-- **Man pages and richer `--help` examples.** Cobra generates basic
-  help. Man pages would be a separate target.
-- **`vaultik snapshot diff <a> <b>`.** Show which files changed between
-  two snapshots, without restoring either.
-- **Status reporting hook for `--cron`.** When a backup fails silently
-  in cron, the user has no idea. A configurable hook on completion, for
-  both success and failure, would close the loop. It could be a
-  webhook, an email or `notify-send`.
+- **Man pages and richer `--help` examples.** Cobra generates basic help. Man
+  pages would be a separate target.
+- **`vaultik snapshot diff <a> <b>`.** Show which files changed between two
+  snapshots, without restoring either.
+- **Status reporting hook for `--cron`.** When a backup fails silently in cron,
+  the user has no idea. A configurable hook on completion, for both success and
+  failure, would close the loop. It could be a webhook, an email or
+  `notify-send`.
 
 ## Infrastructure
 
-- **Schema migrations after 1.0.** Migrations are supported, but none
-  are added before 1.0 because there is no installed base yet. After
-  1.0, each schema change is a new migration, so an existing local
-  index is migrated when `vaultik` is updated. See
+- **Schema migrations after 1.0.** Migrations are supported, but none are added
+  before 1.0 because there is no installed base yet. After 1.0, each schema
+  change is a new migration, so an existing local index is migrated when
+  `vaultik` is updated. See
   [`docs/DATAMODEL.md`](docs/DATAMODEL.md#schema-migrations).
-- **Storage backend coverage tests.** S3, `file://` and `rclone://` all
-  share the `Storer` interface, but the rclone path is the least
-  exercised in CI.
+- **Storage backend coverage tests.** S3, `file://` and `rclone://` all share
+  the `Storer` interface, but the rclone path is the least exercised in CI.