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/database/database.go

@@ -3,8 +3,10 @@
 //
 // Blobs in Vaultik are the final storage units uploaded to S3. Each blob is a
 // large (up to 10GB) file containing many compressed and encrypted chunks from
-// multiple source files. Blobs are content-addressed, meaning their filename
-// is derived from their SHA256 hash after compression and encryption.
+// multiple source files. Blobs are content-addressed: the filename in S3 is
+// hex(SHA256(SHA256(uncompressed blob contents))), computed from the chunk data
+// before compression and encryption (not from the stored bytes). See
+// blobgen.DoubleSHA256 and docs/REPOSTRUCTURE.md.
 //
 // Schema is managed via numbered SQL migrations embedded in the schema/
 // directory. Migration 000.sql bootstraps the schema_migrations tracking

internal/database/models.go

@@ -51,15 +51,15 @@ type Chunk struct {
 // Blob represents a blob record in the database.
 // A blob is Vaultik's final storage unit - a large file (up to 10GB) containing
 // many compressed and encrypted chunks from multiple source files.
-// Blobs are content-addressed, meaning their filename in S3 is derived from
-// the SHA256 hash of their compressed and encrypted content.
-// The blob creation process is: chunks are accumulated -> compressed with zstd
-// -> encrypted with age -> hashed -> uploaded to S3 with the hash as filename.
+// Blobs are content-addressed: the filename in S3 is
+// hex(SHA256(SHA256(uncompressed blob contents))), computed from the chunk data
+// before compression and encryption (not from the stored bytes). See
+// blobgen.DoubleSHA256 and docs/REPOSTRUCTURE.md.
 type Blob struct {
 	ID types.BlobID // UUID assigned when blob creation starts
 
-	// Hash is the SHA256 of the final compressed+encrypted content
-	// (empty until finalized).
+	// Hash is hex(SHA256(SHA256(uncompressed blob contents)))
+	// (empty until finalized); see the type comment above.
 	Hash             types.BlobHash
 	CreatedTS        time.Time  // When blob creation started
 	FinishedTS       *time.Time // When blob was finalized (nil if still packing)