Reported from a dev instance: `column "memory_focus" does not exist` on every chat-session
read, so the task planner chat 500s and never opens — with a startup that reports success.
A ledger row asserts "a migration with this NUMBER ran". That is not the same claim as "this
COLUMN exists" once a migration has been renumbered, and this one was renumbered four times
— 0059 -> 0060 -> 0061 -> 0065 -> 0066 — each time because an upstream batch claimed the
sequence first. A database can therefore carry a row from one numbering while a different
migration owned that number on the boot that recorded it. The applier trusts the ledger
absolutely, skips the migration, and leaves a schema that does not match it. Nothing fails at
startup; everything fails afterwards, because Drizzle's `select()` emits the binary's full
column list and one missing column breaks every read of the table.
The defence already existed one table over: `0047` task recommendations verifies its
materialized column in addition to the marker and replays its idempotent SQL. The lesson had
been learned and not generalized. Both migrations renumbered on this branch — 0066 memory
focus and 0067 session contention wait state — now carry it, and both SQL files are
`ADD COLUMN IF NOT EXISTS`, so a replay over a healthy schema costs nothing.
Two PostgreSQL regression tests reproduce the drifted state exactly (marker present, column
dropped) and prove the replay materializes the column and stays idempotent on a second pass.
pnpm lint 0 errors, test:gate green, core typecheck clean, schema-applier 80/80 against a
real PostgreSQL.
b956a7c8eb