Every EF Core 11 behaviour-change test records whether the upstream change was backported to 10.0 #294

Problem

#288 was found because the 11 line hit an EF Core behaviour change on 11.0.0-rc.1 (#287) and someone then asked whether the same change had been backported to release/10.0. It had (dotnet/efcore#39114), and the 10.x line's CI could not see it (#288). That question was asked by chance, not by procedure.

Change

• Every behaviour-change test the 11 retarget adds (11.0.0-preview.1: retarget main to net11.0 / EF Core 11 / Npgsql 11 after the v10.0.0 tag, with the four behaviour changes as named tests #103's named tests, and any later one written against an EF Core or Npgsql change) records the upstream change it follows and whether it has a release/10.0 (or Npgsql hotfix/10.0.x) backport: a backport PR, "none", or "not checked".
• A conventions test fails on a behaviour-change test without that record, and on "not checked".
• A backport that reaches 10.x gets its own issue against the 10.x line, as 10.x: RangeSet.Contains throws ArgumentException on the EF Core 10 patch that carries dotnet/efcore#37081 #288 did.
• The off-switch registry for EF Core servicing patches (Registry of EF Core servicing off switches (IssueNNNN) between the floor and the newest 10.0 patch, each with a verdict #298) is the cheap way to answer the backport question for EF Core: a backported change carries a Microsoft.EntityFrameworkCore.IssueNNNN switch.

Done when

Every EF Core 11 behaviour-change test names its upstream change and backport status, the conventions test enforces it, and #287 / #288 are the first recorded pair.