Release 10.1.0: open the version on release/10.x, date the changelogs and tag v10.1.0 #301

Change

The steps CONTRIBUTING.md sets for a release on a release branch ("Branches and releases", "Releases on two lines", "A fix that changes an answer"), as PRs against release/10.x. 10.1.0 is a minor because it carries the silent fix #300 (decided 2026-10-19).

1. Open 10.1.0 (first PR, before any fix; tracked as Open 10.1.0 on release/10.x #304): Version to 10.1.0 and PackageValidationBaselineVersion to 10.0.0 in Directory.Build.props; SECURITY.md's supported-versions row to 10.0.x — the latest release on NuGet, never the version being prepared (9.1.x ended at the v10.0.0 tag; SecurityPolicyConventionTests compares the row with the baseline); a ## [10.1.0] section opened in the root changelog and in each affected package changelog (ChangelogConventionTests holds the form). No ### Changed answers heading yet: 10.x on the .NET 11 runtime reads an hour of 24: {24:00:00} parses as {00:00:00} and T24:00:00 as the next day #300's PR adds it.
2. Each fix PR adds its line under ## [10.1.0] and names the consumer stopgap where one exists: AppContext.SetSwitch("Microsoft.EntityFrameworkCore.Issue37216", true) for 10.x: Any/Count over an empty captured list of ranges or value sets fails with 42883: operator does not exist: text && int4range on EF Core 10.0.2 and later (dotnet/efcore#37216) #302, AppContext.SetSwitch("Microsoft.EntityFrameworkCore.Issue37081", true) for 10.x: RangeSet.Contains throws ArgumentException on the EF Core 10 patch that carries dotnet/efcore#37081 #288 once EF Core 10.0.15 ships. 10.x on the .NET 11 runtime reads an hour of 24: {24:00:00} parses as {00:00:00} and T24:00:00 as the next day #300's PR opens the section with ### Changed answers, one row linking 10.x on the .NET 11 runtime reads an hour of 24: {24:00:00} parses as {00:00:00} and T24:00:00 as the next day #300 and the ## Changed answers in 10.1.0 section it adds to docs/migration.md; pr-hygiene.sh refuses a silent PR into a minor without that row, and refuses it into a patch outright, which is why step 1 comes first. release/10.x carries the same ruleset as main, so every PR needs a review and green CI; after one merges, the next is behind and needs gh pr update-branch.
3. Date and tag (last PR): set every ## [10.1.0] heading to the tag date; tag v10.1.0 on the merge commit. The release workflow checks the tag against Version, packs, waits for the nuget environment approval, publishes, creates the GitHub release from the root changelog section and marks it Latest (no higher stable exists).
4. Afterwards: close the 10.x-only issues by hand with a link to their PR (Closes #n acts only on main); a PR on main adds the ## [10.1.0] sections to its changelogs and the ## Changed answers in 10.1.0 section to its docs/migration.md, since main keeps every release's section of both lines; CompanionLineRelease stays empty until 11.0.0 ships.

Done when

v10.1.0 is tagged on release/10.x, the four packages are on NuGet at 10.1.0, the GitHub release exists with the root changelog section as its notes (opening with ### Changed answers), every 10.x-only issue is closed with its PR linked, and main's changelogs and migration guide carry the 10.1.0 sections.

Moved out on 2026-10-19: SECURITY.md on release/10.x naming 10.1.x can only happen when the next 10.x version is opened, because its row follows PackageValidationBaselineVersion. That step is now #331's.