fix(format-v3): transcript versioning in HMAC and atomic upgrade MAC (F-04, F-05)

README.md

@@ -33,8 +33,8 @@ Sanctum ist eine eigenständige, speichersichere und hochperformante CLI-Anwendu
   Alle Schlüsselstrukturen implementieren das `Zeroize`-Trait (`Zeroizing<[u8; 32]>`), um sensible Schlüsseldaten beim Verlassen des Gültigkeitsbereichs im RAM sofort sicher zu nullen. Schlüsseldaten werden mittels `VirtualLock` / `mlock` vor Paging geschützt.
 - **Chunk-Verschlüsselung (AES-256-GCM & 24-Byte AAD, K-02)**:
   Dateien werden in Blöcken von 1 MB verschlüsselt. Als Authenticated Associated Data (AAD) werden `node_id` (8 Bytes LE), `chunk_index` (8 Bytes LE) und `generation` (8 Bytes LE) an jeden Block gebunden. Ein Vertauschen oder Zurücksetzen von Chunks führt zum Authentifizierungsfehler.
-- **Metadaten-Authentifizierung & Replay-Schutz (HMAC-SHA256, K-01 / F-01)**:
-  Ein kryptografischer HMAC-SHA256 (abgeleitet via HKDF `SANCTUM_META_MAC_V3`) bindet den gesamten Verzeichnisbaum deterministisch an den Datenschlüssel (DEK). Das kanonische Transcript sichert nicht nur Inode-Metadaten (Namen, Pfade, Größen, Zeitstempel), sondern auch die sortierte Sequenz aller Chunk-Generationen (`node_id LE64 ‖ chunk_index LE32 ‖ generation LE64`, F-01). Dies schließt Angriffe aus, bei denen ein Angreifer alte Datenbankzeilen gleicher Dateigröße wiederherstellt (Content-Replay).
+- **Metadaten-Authentifizierung & Replay-Schutz (HMAC-SHA256, K-01 / F-01 / F-04)**:
+  Ein kryptografischer HMAC-SHA256 (abgeleitet via HKDF `SANCTUM_META_MAC_V3`) bindet den gesamten Verzeichnisbaum deterministisch an den Datenschlüssel (DEK). Das kanonische Transcript sichert nicht nur Inode-Metadaten (Namen, Pfade, Größen, Zeitstempel), sondern auch die sortierte Sequenz aller Chunk-Generationen (`node_id LE64 ‖ chunk_index LE32 ‖ generation LE64`, F-01). Der HMAC-Input bindet zudem eine explizite Transkript-Version (`b"SANCTUM_META_V3\0" ‖ metadata_gen LE64 ‖ transcript_ver LE32 ‖ canonical`, F-04) ein, was Replay-Angriffe mit alten Metadaten-Blobs nach erfolgter Migration dauerhaft ausschließt.
 - **Dual-Vault (Multi-Slot & Carrier)**:
   Konstante 2-Slot-Architektur. Slot 0 dient als Standard-/Decoy-Vault, Slot 1 als Second Safe (Hidden Vault) oder CSPRNG-Dummy. Dient dem Schutz vor neugierigen Blicken oder beiläufigem Zwang im Alltag. (Hinweis: Die Trägerdatei besitzt hohe Entropie und ist forensisch nachweisbar; kein Anspruch auf juristisch unnachweisbare Abstreitbarkeit gegen behördliche Beschlagnahme).
   *Carrier-Format V2 mit Paged Manifest*: Das steganografische Dateisystem des Hidden Vaults nutzt eine skalierbare Paged-Manifest-Architektur. Blöcke 0 und 1 speichern den redundanten Superblock (C-02), während Inodes über dedizierte Inode-Pages (~1 MB Nutzdaten je Seite, ca. 4.500–7.000 Inodes pro Seite) dynamisch aus dem Blockpool verwaltet werden. Die Kapazität ist nicht mehr auf 7.000 Dateien limitiert, sondern skaliert dynamisch mit den verfügbaren Trägerblöcken. Robuste Fail-Soft-Resilienz (D-01) isoliert Seitenbeschädigungen, ein In-Memory Sekundärindex (D-02) beschleunigt Pfadoperationen auf O(Geschwister), und Sanctum warnt beim Einbinden automatisch bei Blockknappheit (< 20 freie Blöcke oder < 5% Restkapazität).