feat(v2): complete v2 reimplementation

docs/security/repository-encryption.md

@@ -0,0 +1,35 @@
+# Repository encryption threat model
+
+## Status
+
+This document defines the M11 repository-encryption boundary. Encrypted repository
+creation remains disabled until the recovery host-loss acceptance test passes.
+
+## Confidential data
+
+For an `aes-256-gcm` repository, blob contents and signed manifest contents are
+AEAD-encrypted. Data keys and signing private keys are never stored in repository
+metadata, SQLite, logs, command arguments, environment output, or API responses.
+Recovery bundles are separately passphrase-encrypted.
+
+## Intentional leakage
+
+The v1 content-addressed layout retains plaintext SHA-256 blob names. Encryption
+therefore leaks blob equality, object count, repository layout, manifest/backup
+identifiers, and ciphertext sizes derived from plaintext sizes. It does not claim
+to hide those values, a compromised running host with unlocked keys, source data
+while it is read, or a recovery-bundle passphrase.
+
+## Key lifecycle
+
+Encryption uses distinct data and signing keys. Rotation creates a new data-key
+epoch for subsequent objects and retains historical epochs so existing backups
+remain verifiable and restorable. It neither changes immutable repository policy
+nor rewrites existing objects.
+
+## Recovery boundary
+
+Recovery export, validation, and import are local CLI operations only. A bundle
+contains the required key material and an authenticated catalog; passphrases are
+not accepted on command lines. Bundle parsing must reject malformed or unsupported
+parameters without revealing whether a passphrase, key, or ciphertext was wrong.