fix(core): let a rebuildable Invalid delta through AssertPatchingIsValid

[jeremydmiller]

Closes #538.

The gap

SchemaMigration.AssertPatchingIsValid threw for SchemaPatchDifference.Invalid on every AutoCreate except All, without asking whether the delta could actually apply the change. Both apply paths directly below it do ask:

• SchemaMigration.WriteAllUpdates
• Migrator.WriteUpdate

Both honour ISchemaObjectDeltaWithRebuild.CanRebuildInPlace and call WriteUpdate rather than drop-and-create — which is what #477 added so a rebuild would copy the data instead of discarding it. The gate was stricter than the thing it gates.

The fix

var invalids = _deltas
    .Where(x => x.Difference == SchemaPatchDifference.Invalid)
    .Where(x => x is not ISchemaObjectDeltaWithRebuild { CanRebuildInPlace: true })
    .ToArray();

if (invalids.Any())
{
    throw new SchemaMigrationException(autoCreate, invalids);
}

The open question, decided: CreateOnly still refuses

A rebuild recreates a table that is already there, which is an update however you look at it. This needs no special case — the delta is still Invalid, so the migration's Difference is still not Create, and the existing CreateOnly branch throws. Pinned by a test in both suites rather than left to fall out silently.

The doc said the opposite, and was wrong on its own terms

ISchemaObjectDeltaWithRebuild's XML doc claimed a rebuild always requires AutoCreate.All, because a rebuild that also drops a column takes that column's data with it.

That reasoning does not survive contact with the code. AssertPatchingIsValid could only express it by refusing every rebuildable delta, including the great majority that drop nothing — a column type change, a foreign key, a primary key. And measured against a real SQLite database: the ordinary Update path already emits ALTER TABLE … DROP COLUMN and is already permitted under CreateOrUpdate. So the strict rule was not buying the protection it claimed; it refused the same data loss only when the dropped column happened to sit in a key, and refused three harmless changes to do it.

The doc is rewritten to record the decision and the measurement, and keeps the point that is still worth knowing: a rebuild copies every row, so on a large table it is a very different proposition from an ALTER.

Reproduction

The issue cites Weasel.Sqlite.Tests/Tables/numeric_upgrade_rebuild.cs, which does not exist on master — so the reproduction is built here from scratch, in the 9.28.0 upgrade shape: a table created when numeric mapped to REAL, against a model that now asks for NUMERIC. Confirmed failing before the change:

Shouldly.ShouldAssertException : `migration.AssertPatchingIsValid(AutoCreate.CreateOrUpdate)`
should not throw but threw Weasel.Core.SchemaMigrationException
with message "Cannot derive schema migrations for Weasel.Sqlite.Tables.TableDelta AutoCreate.CreateOrUpdate"

Tests

Weasel.Core.Tests/Migrations/rebuildable_invalid_deltas_pass_the_gate.cs — the rule is a Core rule, so it is tested at Core with fakes: permitted under All/CreateOrUpdate, refused under CreateOnly, still refused when CanRebuildInPlace is false, still refused for a delta not implementing the interface, and a mixed migration refused with only the genuinely stuck delta named in the message.

Weasel.Sqlite.Tests/Tables/rebuildable_invalid_is_permitted.cs — end to end against a real database, since SQLite is the only provider implementing the interface today. Asserts the permission is worth something: the migration it lets through converges to None and the row survives with its value.

Full Weasel.Core.Tests (327) and Weasel.Sqlite.Tests (523) green.

Docs

docs/release-9-28.md documented this as a known break with "stay on 9.27 until the guard is fixed". Rewritten for 9.28.1, keeping the workaround for anyone already on 9.28.0, and noting that the gap was never specific to numeric — it affected any SQLite column type change, foreign key change or primary key change.

🤖 Generated with Claude Code

[jakobt]

Would be good to get #539 before this because a table rebuild can in some cases fail halfway through and live database in unfortunate state.