SchemaKit: moving from EFCore.ComplexIndexes 5.x adds no migration, or exactly the one the guide documents #59

Problem

The spin-off (#37) asks every consumer to make two changes when they move to EF Core 11: swap EFCore.ComplexIndexes 5.x for SchemaKit, and move what EF Core 11 and Npgsql 11 now do natively to the native API (#39). If the swap changes an index or constraint name, or leaves behind an annotation the new differ doesn't read, the consumer's next migration drops and recreates indexes and constraints on production tables. It does so without any error, which is exactly what the silent label is for.

This test is what makes the spin-off acceptable.

Change

One end-to-end test per feature:

1. Start from a model and a snapshot generated by EFCore.ComplexIndexes 5.x, checked in.
2. Rewrite the same model for SchemaKit as the migration guide says: native HasIndex for complex-type indexes, native WithoutOverlaps/WithPeriod wherever SchemaKit: leave out what EF Core 11 and Npgsql 11 do natively; keep what stays unique #39 leaves temporal constraints to the platform, SchemaKit for the rest.
3. Run migrations add. It must produce no operations, or exactly the ones the migration guide lists.

Run it on PostgreSQL 16 and 18 and on SQL Server.

Done when

• Every feature 5.x ships has its test.
• The migration guide's "EFCore.ComplexIndexes 5.x → SchemaKit" section is checked against these tests.
• It ships before 11.0.0.