Fix the six findings of the review on config set, version and blob names

README.md: config set keeps comments and can remove blank lines; a
config that does not load yet also has a value that is not a size
refused; vaultik version reports a tag and adds a development-build
note to every other version. docs/REPOSTRUCTURE.md and README.md:
someone who has a blob's whole contents can compute its name and see
whether it is stored. docs/DATAMODEL.md: snapshot list shows an
unfinished snapshot as remote only once its manifest is at the
destination; closing a full blob commits the first chunk of the next
one. internal/cli/config.go: config set --help says the same about
comments and blank lines.

Model: fable-5-1

docs/DATAMODEL.md

@@ -195,8 +195,9 @@ example is `server1_home_2025-06-01T12:00:00Z`. It has three parts:
 The `snapshot list` table shows `uncompressed_chunk_size` as `UNCOMPRESSED SIZE`
 and `new_chunk_size` as `NEW CHUNK SIZE`.
 
-A snapshot with `completed_at` set to `NULL` is unfinished. `snapshot list` does
-not show it. The next backup deletes it, and so does `prune`.
+A snapshot with `completed_at` set to `NULL` is unfinished. `snapshot list`
+shows it only when its manifest is at the destination, and then as remote only.
+The next backup deletes it, and so does `prune`.
 
 ### `snapshot_files`
 
@@ -324,7 +325,8 @@ Storing a changed file writes these rows:
 
 - A row in `blobs`, when packing of a blob starts.
 - When the blob is closed, in one transaction:
-    - a row in `chunks` for each new chunk in the blob
+    - a row in `chunks` for each chunk queued since the last blob was closed.
+      When a blob is full, that includes the first chunk of the next blob.
     - the blob's rows in `blob_chunks`
     - the blob's `blob_hash`, sizes and `finished_ts`
 - When the blob is stored at the destination, in one transaction:

docs/REPOSTRUCTURE.md

@@ -94,13 +94,16 @@ A blob's name is `hex(SHA256(SHA256(uncompressed contents)))`. The contents are
 the chunk data, joined in order, before compression and encryption. The name is
 not a hash of the stored bytes.
 
-This has two consequences:
+This has three consequences:
 
 - Checking a blob against its name needs the private key. The blob must be
   decrypted and decompressed first. `snapshot restore` and
   `snapshot verify --deep` do this.
 - Without the key, only a blob's presence and size can be checked.
   `snapshot verify` does this.
+- Someone who has the whole contents of a blob can compute its name, and so see
+  whether it is stored. This works for a file they have that fills blobs on its
+  own.
 
 `blobgen.DoubleSHA256` in `internal/blobgen` computes the name.
 
@@ -224,6 +227,7 @@ Someone who can read the destination therefore learns these:
 - when each backup finished
 - how many blobs each snapshot uses, and how large they are
 - which blobs two snapshots share
+- whether a blob holds data they already have in full
 - whether a snapshot ID they guess exists
 
 They do not learn these: