Refuse EF Core 11 at registration: EFCore.ComplexIndexes serves EF Core 10 only #55

Problem

From EF Core 11 on, this package's successor is CodoMetis.EFCore.SchemaKit (#37). EFCore.ComplexIndexes stays the EF Core 10 package (LTS, supported to 2028-11) and takes fixes only after 5.5.0 (#36).

The dependency ceilings ([10.0.0, 11.0.0) on EF Core and on Npgsql) don't keep an EF Core 11 application out. Most applications reference Npgsql.EntityFrameworkCore.PostgreSQL directly, and a direct reference to 11 wins over the transitive ceiling with NU1608, a warning. The package then runs on EF Core 11. #47 showed it even builds and passes there unchanged, so the first sign of trouble would be an issue filed here about a line this repository doesn't serve.

The check must be on the EF Core major, never on the runtime: a net10.0 package installs into a net11.0 application, and EF Core 10 on the .NET 11 runtime is a combination Microsoft supports. Those users belong here.

Change

• Every registration entry point (UseNpgsqlComplexIndexes(), the SQL Server and core options extensions, and the design-time registration) throws InvalidOperationException when EF Core's assembly major is not 10. The message names CodoMetis.EFCore.SchemaKit as the package for EF Core 11.
• The check reads the version through one internal helper, so a test can feed it a version.
• The bug report form gets a required "EF Core version" field that offers 10.x only, with a line pointing EF Core 11 users to SchemaKit.
• Each package README opens with one sentence pointing EF Core 11 users to SchemaKit.

Tests

One test per entry point: version 11 throws with the message, version 10 passes. Remove the check and show the tests fail.

Release

5.5.0, a minor: it refuses a configuration the package never supported. The ids are not deprecated on nuget.org while EF Core 10 is supported, because deprecation would tell EF Core 10 users not to use the only package that serves them.