Write a MIGRATION.md ledger Claude Code re-reads every session of a multi-week migration

Write this as MIGRATION.md at the repository root. This file is not a one-off report — it is a living ledger a fresh Claude Code session will read at the start of every future sitting on this migration, possibly weeks apart, with no memory of earlier sessions beyond what is written here. Its job is to make a half-finished migration resumable by a session that has never seen it before.

MIGRATION
Express 4 to Fastify 4 on the internal billing API — moving from 12 Express route files under src/api/billing/, using Express-style middleware chains to Same 12 routes reimplemented as Fastify plugins with schema-based request validation.

STRATEGY
State the chosen approach explicitly — strangler-fig (old and new run side by side behind a seam until the old path is deleted) or big-bang (one atomic cutover) — and why: Strangler-fig — both servers run behind a feature-flagged router until every route is migrated and verified, since billing cannot tolerate a single atomic cutover risk. Never let a session default to whichever approach is easier for the file it happens to be looking at; the strategy is fixed for the whole migration.

FREEZE LINE
Name the exact boundary of what is in scope. Anything outside 12 Express route files under src/api/billing/, using Express-style middleware chains's stated boundary is frozen — do not refactor it, rename it, or 'improve it while I'm in there,' even if it looks related. A migration that scope-creeps into adjacent code is a migration that never finishes and is hard to review as one coherent change.

LEDGER
Maintain a table of every unit being migrated (file, module, or route) with three columns: status (pending / in progress / migrated / verified), the commit or PR that moved it, and any compatibility shim it still depends on. Update this table as the last step of every session, not as an afterthought — a session that migrates three files and forgets to update the ledger has made the next session's job harder than doing nothing at all.

VERIFICATION PER UNIT
A unit only moves to 'verified' after running npm run test:contract -- --grep billing (runs recorded-request contract tests against both old and new route for identical input) against it specifically, not just the full suite passing in aggregate. State what 'passing' means for this migration precisely — same output, same behavior under the old code path's known edge cases, or a named acceptance test — since 'the tests are green' can be true while the migration is still behaviorally wrong.

ROLLBACK
For each migrated-but-not-yet-verified unit, state how to revert it alone without reverting the whole migration. If no per-unit rollback is possible for this strategy, say so plainly rather than leaving it implied.

HARD RULES
- Never delete the old code path for a unit until its ledger row says verified.
- Never migrate a unit not yet reached in Strangler-fig — both servers run behind a feature-flagged router until every route is migrated and verified, since billing cannot tolerate a single atomic cutover risk's intended order just because it looks quick.
- Never mark a unit verified based on the migration compiling — compiling is not passing.

WHEN A SESSION ENDS MID-MIGRATION
Leave the ledger in a state where the very next row needing attention is unambiguous — the next session should be able to read this file top to bottom and know exactly where to resume without re-deriving it from a git log.