Implement YAML versioning and migrations

Problem

Dashboard YAML files have no schema version marker, and the compiler has no mechanism to detect or migrate documents written against an older schema. When the YAML contract evolves (new fields, renamed keys, changed semantics), existing dashboards break silently at compile time or produce incorrect normalized output with no indication that a migration is needed. Users have no way to distinguish "my YAML is wrong" from "the schema changed and my file is outdated," making every contract change a potential breaking change for all existing dashboards.

Context

• Related: declarative-schema-definition-outside-python-code — a formal schema definition makes version diffing and automated migrations possible. Versioning needs a schema to version against.
• Research: ai_notes/research/json-render-deep-dive.md — json-render's schema system as prior art for declarative spec definitions.

Possible Solutions

• A - Keep the contract unversioned and document breaking changes manually: simple, but too fragile.
• B - Add a version field but require manual rewrites by users on every breaking change: explicit, but high-friction.
• C - Recommended: add schema version markers plus a migration framework that can detect outdated documents, explain the gap, and offer automated transforms where practical.

Plan

1. Define the authored version marker and compiler behavior for missing or old versions.
2. Design the migration contract, including how transforms are registered and tested.
3. Prototype one migration path on a representative schema change.
4. Document upgrade behavior, CLI ergonomics, and rollout rules for future contract changes.

Implementation Progress

• Confirm scope and acceptance with milestone owner.

• Milestone readiness signal is updated.

• Track blockers and mitigation owner.

Review Feedback

• [ ] Review cleared