# Schema baseline cleanup was generalized into migration deletion policy

## Summary

A one-time Workspace SQLite baseline cleanup in `89856eb7` was documented as a permanent policy
that retained historical migrations were not part of the contract. Later schema changes followed
that text by deleting the immediately preceding migration whenever a new version was added.

This left valid dogfooding databases stranded. A schema-50 database could run the historical
50-to-51 migration, but the schema-52 binary required a fresh schema-51 baseline and rejected the
resulting two-row history. The current schema-53 binary retained only 52-to-53. The CLI also listed
`migrate` as an expected command after its implementation had been removed.

## Why this was harmful

A request or decision to retire sufficiently old generations does not imply that every migration
should be discarded at the next version bump. Treating a baseline reset as a standing policy
removed the only executable data-preservation path without an explicit retention decision or
operational replacement.

The narrow tests reinforced the mistake: each version tested only a freshly constructed previous
baseline, not a database migrated from the oldest retained version through the full chain.

## Corrective rules

- Keep an ordered, composable migration chain from an explicit oldest supported version.
- Do not infer migration retirement from a schema-version increment.
- Require a separately reviewed baseline-retirement change and operational plan.
- Test the oldest retained fixture through every migration to the latest schema.
- Make startup migration and explicit migration CLI use the same planner and runner.
- Make dry-run execute the real path against an in-memory SQLite backup rather than maintaining a
  second approximation.