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