Background: The revised KEK design (SPM-4460) introduces a v2 KEK page format with a timestamp field, alongside the existing v1 format. Per Option C in the design doc, full compatibility is required — customers must be able to upgrade from v1 to v2, downgrade back to v1, and re-upgrade, without losing key data.

Without explicit test coverage of these transitions, a compatibility regression could go undetected until it surfaces in production, potentially months or years after the change.

Acceptance Criteria:

• Upgrade: a database with v1 KEK pages can be opened by v2 code; key data is accessible and timestamp is treated as 0
• Downgrade: a database with v2 KEK pages can be opened by v1.1 code; timestamp field is ignored and key data remains accessible
• Re-upgrade: a database that has gone through v1 -> v2 -> v1.1 -> v2 transitions works correctly with mixed-format KEK pages in storage
• All transitions are covered by automated tests