Rotating the key only makes the purged blocks unreadable once the old key is destroyed, and since Foxstash never holds the key, that last step sits with the app. NIST SP 800-88 Rev. 2 calls this cryptographic erase and defines it as sanitizing the keys, so recovery becomes infeasible because the old key is gone, not because a new one exists. If the meeting recorder keeps old keys around so it can still open older files, the deleted meeting is still recoverable from those blocks.

That runs into your retention default of 2. The old key can only go once no file on disk still needs it, so the order would be purge, rotate, then compact until the fallback checkpoint is also written under the new key, and only then destroy the old one. Destroy it too early and the fallback becomes a file nobody can open. Having the purge report list which key generation each surviving file was written with would tell the app when destroying the old key is safe.