Correct remote layout and privacy docs for hashed snapshot keys (closes #67)

Three documents showed the remote layout with a plaintext snapshot ID as the metadata directory name, and docs/REPOSTRUCTURE.md blamed those IDs for the observable backup time. The store actually names each metadata directory with a one-way hash of the ID, so hostname and snapshot name are not visible; the backup time is, through the plaintext timestamp in the manifest, which is accepted behaviour.

README, ARCHITECTURE.md, docs/DATAMODEL.md and docs/REPOSTRUCTURE.md now show the hashed layout, the derivation is documented once, and the privacy section lists what the unencrypted manifest exposes. Two code comments that claimed the timestamp was hidden are corrected. No behaviour change.

Judgement call: docs/DATAMODEL.md was not named in the issue but had the same error.

model: claude-opus-4-8 (implementation, review); claude-fable-5-1 (merge)

README.md

@@ -344,7 +344,7 @@ both are set.
 ├── blobs/
 │   └── <aa>/<bb>/<full_blob_hash>
 └── metadata/
-    └── <snapshot_id>/
+    └── <remote-key>/
         ├── db.zst.age          # Encrypted binary SQLite database
         └── manifest.json.zst   # Unencrypted blob list (for pruning)
 ```
@@ -355,8 +355,18 @@ both are set.
 * `manifest.json.zst` is an unencrypted compressed JSON blob list, enabling
   pruning without the private key
 
-Snapshot IDs follow the format `<hostname>_<snapshot-name>_<RFC3339-timestamp>`
-(e.g. `server1_home_2025-06-01T12:00:00Z`).
+Snapshot IDs follow the human-readable format
+`<hostname>_<snapshot-name>_<RFC3339-timestamp>` (e.g.
+`server1_home_2025-06-01T12:00:00Z`), but this ID is never written to the
+destination store in plaintext. Each snapshot's metadata directory is named
+with its `<remote-key>`, a one-way double SHA-256 hash of the ID, so a listing
+of the store reveals no hostname or snapshot name. The backup time is not
+hidden: manifest.json.zst carries a plaintext timestamp, and object
+modification times are visible at the storage layer regardless. For example,
+`server1_home_2025-06-01T12:00:00Z` is stored under
+`metadata/17f97bcde958748af076b926af59823943db59e80ce7170b40f124dfa28f64aa/`.
+See [docs/REPOSTRUCTURE.md](docs/REPOSTRUCTURE.md#remote-key-derivation) for the
+derivation.
 
 ### data flow
 
@@ -373,7 +383,7 @@ Snapshot IDs follow the format `<hostname>_<snapshot-name>_<RFC3339-timestamp>`
 
 **restore:**
 
-1. Download and decrypt `metadata/<snapshot_id>/db.zst.age`
+1. Download and decrypt `metadata/<remote-key>/db.zst.age`
 2. Open the binary SQLite database
 3. Query files (optionally filtered by paths)
 4. Download and decrypt required blobs