Prove temporary V2 storage and recovery before application cutover #5809

🤖 Generated by the Agentic Engineer

Summary

Enable the prepared temporary V2 storage targets and prove restore, persistence and reattachment before moving application data.

Motivation

The migration must establish a working V2 data path and verified recovery before replacing any existing application storage. The temporary-storage route also needs its own activation checks; the earlier filesystem-staging procedure cannot authorize it.

Proposed Solution

Resume the existing private activation and canary work under #5582 on the current reviewed foundation. Provide separately confirmed, protected operations for the prepared temporary targets and a disposable V1-to-V2 restore proof. Keep activation off until its native prerequisites pass, and retain journals and uncertain resources for explicit recovery.

Acceptance Criteria

• Bind every selected temporary target to its reviewed identity, encrypted raw storage, native memory reservation, capacity budget and owned preparation proof before registration.
• Enable V2 through the declarative owner only after the required independent storage targets and host prerequisites are proven.
• Verify actual V2 engine, frontend and required replica health.
• Restore a known disposable V1 payload onto V2, compare its content, and verify persistence after reattachment on separate qualified workers.
• Prove cleanup of only the canary's owned scratch resources, including retained storage; uncertain outcomes preserve their journal and resources without replay.
• Exercise both disabled and enabled admission states and interrupted recovery paths in tests.
• Record actual protected production acceptance before closing; CI or a queued PR alone is insufficient.

Alternatives Considered

Changing a StorageClass does not migrate existing data. Reusing filesystem-staging authorization for raw targets would not prove the new route. Application cutover remains separate work under #5582.

Additional Context

Priority: this is on the critical path to the maintainer-requested V2 migration. It resumes already-started work; it does not add an unrelated feature.

Native prerequisites are tracked in #5791 and #5787. Baseline and interruption recovery remain governed by #5665 and the existing strict current-source policy.