`migrate()` skips everything `<= MAX(version)`, which made an integer
the entire identity of a schema. It is not, and two failures followed
from that, both silent:
1. A database migrated by a NEWER build. Every migration is already
"applied", so the runner does nothing and the caller reads a schema
it has never seen. Additive columns survive; a shape change does not.
2. A database at the SAME version but a different shape, because a
migration file changed after it had already run somewhere — a
revised migration, a hand-edited file, an abandoned branch. Version
numbers match, so nothing compared anything.
Both corrupt cumulatively: every subsequent write goes through code
whose assumptions about the row shape are wrong, and the user has no
signal until something much later fails for an unrelated-looking reason.
Migration 017 adds a nullable `checksum` column; the runner records the
sha256 of the file it actually executed. `assert_schema_compatible`
checks both failure modes and runs at the top of `migrate()`, so no
caller can forget it.
NULL is treated as "unknown", never "mismatched". Rows applied before
017 existed cannot retroactively grow a checksum, and backfilling them
from the files on disk would assert exactly the compatibility the check
exists to verify. So the version-ahead half protects every database
immediately; the divergence half protects migrations from 018 onward.
DumiFlex
8cf40241cf