Fix the ten findings of the review on the destination, the marker file and chunk sizes

README.md: the "Getting started" destination advice, the Full Disk Access
paragraph moved above the block with the reopen step, the mount-point
case, the remote nuke failure sentence, the hostname setting, the upload
order under "Sharing a destination", the confirmation list and the dev
stamp sentence. configs/config.example.yml: the storage_url and
blob_size_limit comments. docs/ARCHITECTURE.md and docs/DATAMODEL.md:
the Snapshot ID and Marker file terms, and "marker file" in place of
"destination marker".

Model: fable-5-1

docs/ARCHITECTURE.md

@@ -16,12 +16,16 @@ Two other documents cover the stored data:
 ## Terms
 
 - **Snapshot**: one backup of the paths listed under one name in the config.
+- **Snapshot ID**: the name of a snapshot, in the form
+  `<hostname>_<snapshot-name>_<timestamp>`.
 - **Chunk**: a piece of a file's content. A chunk is named by the SHA-256 hash
   of its content.
 - **Blob**: one object at the destination. It holds many chunks, compressed and
   then encrypted.
 - **Local index**: the SQLite database on the backed-up machine.
 - **Destination**: the place the backups are stored.
+- **Marker file**: `vaultik-destination.txt` at the destination. See
+  [The marker file](REPOSTRUCTURE.md#the-marker-file).
 - **Manifest**: the unencrypted list of the blobs one snapshot uses.
 - **Remote key**: a hash of the snapshot ID. It names the snapshot's directory
   at the destination.
@@ -292,10 +296,10 @@ therefore marks a backup that did not finish.
   checks its chunk hashes.
 
 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.
+there, the restore checks the marker file and lists the snapshot's directory.
+Given a remote key, it reads the local index only to check the marker file. 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

@@ -17,11 +17,15 @@ copy that was uploaded with the snapshot.
 ## Terms
 
 - **Snapshot**: one backup of the paths listed under one name in the config.
+- **Snapshot ID**: the name of a snapshot, in the form
+  `<hostname>_<snapshot-name>_<timestamp>`.
 - **Chunk**: a piece of a file's content, named by the SHA-256 hash of that
   content.
 - **Blob**: one object at the destination. It holds many chunks, compressed and
   then encrypted.
 - **Destination**: the place the backups are stored.
+- **Marker file**: `vaultik-destination.txt` at the destination. See
+  [The marker file](REPOSTRUCTURE.md#the-marker-file).
 - **Manifest**: the unencrypted list of the blobs one snapshot uses.
 - **Remote key**: a hash of the snapshot ID. It names the snapshot's directory
   at the destination.
@@ -367,7 +371,7 @@ still be in the `-wal` file beside it.
 
 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.
+marker file.
 
 - It downloads and decrypts `db.zst.age` into a temporary directory.
 - It opens that file read-only. It applies no migration to it.