Record each snapshot's new chunk size when its backup runs (closes #311)

snapshot list worked out NEW CHUNK SIZE from the snapshot's file rows. A
file's row is shared by every snapshot that lists it and rewritten when
the file changes, so a snapshot whose change was a modified file showed
0 B, and older snapshots' figures moved after later backups.

The scanner now totals the size of the chunks it stores that were not
stored before (the chunks chunk_count counts), the backup writes that
total to a new snapshots column, new_chunk_size, and snapshot list reads
it.

Judgement call: the figure is fixed when the backup runs, so removing an
earlier snapshot no longer raises a later snapshot's figure.

Model: opus-5-5

README.md

@@ -293,8 +293,8 @@ needed.
 **`snapshot list`**: Show every snapshot known to this host — the union
 of the local index and the backup destination store — with timestamps
 and three sizes per snapshot (compressed remote size; total
-uncompressed chunk size; size of chunks newly referenced by that
-snapshot).
+uncompressed chunk size; size of the chunks that snapshot stored that
+were not stored before, recorded when its backup ran).
 
 Listing the destination store does **not** require the age secret key,
 so it works in vaultik's intended configuration, where the backed-up
@@ -307,8 +307,8 @@ only the hash, so hostname and snapshot name exist solely in the local
 index and in the encrypted per-snapshot database. Snapshots found only
 on the destination store are therefore listed as
 `<remote only:<abbreviated remote key>>` and show `<remote only>` in
-the uncompressed and "new chunk" columns, which can only be computed
-from the local index. Their timestamp and compressed size are real,
+the uncompressed and "new chunk" columns, which come only from the
+local index. Their timestamp and compressed size are real,
 read from the manifest.
 
 Snapshots in the local index with no counterpart on the destination