fix: validate legacy template ownership before migration

[PatrickSys]

Legacy init --migrate renames .planning to .work before validating template ownership and destination tracking policy. If those checks refuse initialization, the consumer is left with a moved state root despite the failed command.

Run the existing template/config/tracking preflight against the legacy directory before renaming, using .work as the destination identity. Revalidate after migration before applying generated changes. Add regression coverage for missing, corrupt, incomplete and unowned template state, a destination tracking conflict, repeated refusals, and a valid migration that preserves unrelated consumer bytes.

Verified on Linux with Node v24.19.0:

• Five refusal cases failed before the fix; all six new regression cases pass with it.
• node tests/run-all.cjs: all 30 test files pass; the accepted-failure list is empty.
• node tests/run-proof.cjs: clean across 11 tracked runners after fetching the historical b7c8b7bd54e1764826cb55763440a676181bc851 pin. This checks proof staleness, not execution of the pinned proofs.
• The locally packed CLI passes three consumer cases across five child processes: unchanged bytes on refusal and retry, destination tracking refusal before rename, and successful owned-template migration followed by reinitialization.
• git diff --check: clean.

This addresses pre-rename template and tracking refusals. It does not make all later initialization writes atomic or repair consumers already left in a partially migrated state. The PC tunnel was unavailable, so this is a candidate against committed main 61b27708; the local .work/ROADMAP.md and uncommitted PC changes could not be checked.

Context: persisted consumer-recovery recommendation.