[buvinghausen]

Fixes #4111

Changes

• Bump EF Core and Microsoft.Extensions to 11.0.0-rc.3.26522.148 (the October 2026 out-of-band security release), the SDK in global.json to 11.0.100-rc.3.26522.148, and VersionPrefix to 11.0.0-rc.3.
• Replace the exact EF pins ([x]) with [$(EFCoreVersion), 12.0.0-a), the same range EF Core's own packages use (e.g. Relational → EFCore is >= 11.0.0-rc.3.26522.148 && < 12.0.0-a). Users can then pick up newer EF previews/RCs/patches, like this unplanned RC3, without waiting for a new EFCore.PG release. 12.0.0-a sorts before every 12.0.0-alpha/preview/rc, so the next major is excluded.
• Remove the direct Microsoft.EntityFrameworkCore reference/PackageVersion. It already comes in transitively through Microsoft.EntityFrameworkCore.Relational.

Resulting nuspec dependencies:

<dependency id="Microsoft.EntityFrameworkCore.Relational" version="[11.0.0-rc.3.26522.148, 12.0.0-a)" include="All" />
<dependency id="Npgsql" version="10.0.3" exclude="Build,Analyzers" />

Notes for review

• This intentionally reverses the earlier policy of locking preview dependencies to an exact version. That policy guarded against provider-facing breaking changes between previews. The tradeoff: a user who moves to a newer EF prerelease could hit a provider break that an exact pin would have blocked at restore. Since EF's own packages already ship with this range, that seemed acceptable.
• I checked that the EF analyzer (Microsoft.EntityFrameworkCore.Analyzers) still reaches consumers without the direct EFCore reference: a scratch project referencing the packed nupkg gets /analyzer:...Microsoft.EntityFrameworkCore.Analyzers.dll on the compiler command line.

Testing

• EFCore.PG.Tests: 766 passed, 0 failed.
• EFCore.PG.FunctionalTests: 29,047 passed, 7 failed. The same 7 fail on main with rc.2:
  • 6× *GearsOfWarQueryNpgsqlTest.DateTimeOffset_Date_returns_datetime depend on the local timezone and pass with TZ=UTC.
  • TPCInheritanceQueryNpgsqlTest.Can_insert_update_delete also fails locally on main.