Correct the security claims in docs and comments, and record the accepted risks (closes #171)

Docs and comments only; no behaviour change. Corrects ten overclaims the security review found: snapshot names are hashed but the hash uses no secret, so a guessed hostname and name can be confirmed; a blob is named by hex(SHA256(SHA256(uncompressed contents))), stated once in docs/REPOSTRUCTURE.md and referenced elsewhere; double hashing does not hide known content (blob packing does); age uses ChaCha20-Poly1305, not XChaCha20; encryption is required, not optional; a snapshot is marked complete before its metadata is uploaded; the export comment now matches its only caller; deep verify detects corruption, not authorship; adding a recipient does not reach existing data; restore examples target a user-owned directory.

Adds an Accepted Risks subsection under Security Considerations with the seven documented risks, cross-referenced from the README.

Model: opus-4-8

internal/blob/packer.go

@@ -1,14 +1,16 @@
 // Package blob handles the creation of blobs - the final storage units for Vaultik.
 // A blob is a large file (up to 10GB) containing many compressed and encrypted chunks
-// from multiple source files. Blobs are content-addressed, meaning their filename
-// is derived from the SHA256 hash of their compressed and encrypted content.
+// from multiple source files. Blobs are content-addressed: a blob's filename is
+// hex(SHA256(SHA256(uncompressed blob contents))), computed from the concatenated
+// chunk data before compression and encryption, not from the stored bytes. See
+// blobgen.DoubleSHA256 and docs/REPOSTRUCTURE.md.
 //
 // The blob creation process:
-// 1. Chunks are accumulated from multiple files
-// 2. The collection is compressed using zstd
-// 3. The compressed data is encrypted using age
-// 4. The encrypted blob is hashed to create its content-addressed name
-// 5. The blob is uploaded to S3 using the hash as the filename
+//  1. Chunks are accumulated from multiple files
+//  2. Each chunk's uncompressed bytes are fed to a running SHA-256 and, in the same
+//     pass, compressed with zstd and encrypted with age into the temp file
+//  3. On finalize, the name is the double SHA-256 of that uncompressed content
+//  4. The blob is uploaded to S3 using the name as the filename
 //
 // This design optimizes storage efficiency by batching many small chunks into
 // larger blobs, reducing the number of S3 operations and associated costs.