docs(kms): clarify rotation features and disk rollback

Signed-off-by: Kevin Wang <wy721@qq.com>

Author: kvinwang

CHANGELOG.md

@@ -7,6 +7,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Added
+
+- KMS root and application key epochs, epoch-scoped authorization, SealedEnv
+  HPKE encryption, automatic environment migration, and epoch-aware SDK key
+  selection.
+
 ### Changed
 
 - KMS: retain `GetTempCaCert`, temporary CA files and legacy handover fields so

docs/app-key-epochs.md

@@ -49,9 +49,12 @@ regardless of epoch selection; historical responses cannot replace that pin.
 The guest migrates disk headers and environment ciphertext if either dimension
 changes and rejects future epochs in either dimension. LUKS tokens record both
 epochs (missing app epoch means zero). Rekeying replaces the keyslot wrapping key;
-it does not rotate the volume encryption key or erase host snapshots. App
-rotation isolates future app keys from an exposed old derived key, but cannot
-recover from compromise of the KMS root or revoke already disclosed secrets.
+it does not rotate the volume encryption key or erase host snapshots. Once a disk
+header carries an epoch token, older guest images reject that header as malformed;
+reverting the VM image therefore requires migrating the disk with a compatible
+image or restoring a compatible header backup. App rotation isolates future app
+keys from an exposed old derived key, but cannot recover from compromise of the
+KMS root or revoke already disclosed secrets.
 
 ## SDK selection