Align the .NET servicing train to 10.0.10/9.0.18 and hand-manage the Microsoft.OpenApi pin

[Vulthil]

Summary

• Aligns every package on the .NET servicing train that dependabot's open deps PR left mixed: the shared FrameworkVersion property (EF Core packages, Mvc.Testing, AspNetCore.OpenApi) moves 10.0.9 → 10.0.10 with its net9.0 leg 9.0.17 → 9.0.18, the eight literal Microsoft.Extensions.* entries move 10.0.9 → 10.0.10, and Microting.EntityFrameworkCore.MySql moves 10.0.9 → 10.0.10. Dependabot cannot raise a version property shared by multiple packages, so its PR bumped only the literals and would have shipped EF/ASP.NET Core at 10.0.9 next to Extensions at 10.0.10.
• Bumps the Microsoft.OpenApi pin's net10.0 leg 2.9.0 → 2.11.0 (staying on the GHSA-v5pm-xwqc-g5wc-patched 2.x line). The net9.0 leg stays 1.6.17, which is exactly Microsoft.AspNetCore.OpenApi 9.0.18's own dependency floor (verified from its nuspec — ASP.NET Core 9 consumes the 1.x line, not 2.x). The 10.0.10 nuspec still floors at Microsoft.OpenApi 2.0.0, so the pin's removal condition (floor past 2.7.5) has not been met and the pin stays.
• Changes the dependabot ignore rule for Microsoft.OpenApi from majors-only to all updates: dependabot flattens conditional MSBuild property definitions to a single value, so its deps PR rewrote the net9.0 leg 1.6.17 → 2.11.0 — pairing ASP.NET Core 9's OpenApi package with the incompatible 2.x line. The majors-only rule couldn't catch this (2.9.0 → 2.11.0 is a minor at the property's default leg), so the pin is now hand-managed; NuGetAudit still fails CI on real advisories regardless.
• Deliberately untouched: Microsoft.Extensions.Http.Resilience / Microsoft.Extensions.ServiceDiscovery (their own 10.7 → 10.8 minor line) and the tooling/OTel/analyzer bumps — those stay with the dependabot PR, which shrinks to just that set on its next rebase.

Verification

• All bumped versions verified to exist on nuget.org (flat-container index) before editing, including EF Core 10.0.10/9.0.18 and the Microting fork's 10.0.10.
• dotnet restore: clean — no NU1102, no new audit warnings.
• Full CI-parity run (./eng/coverage.ps1: Release build on both TFMs, all suites including the Docker-backed provider tests and the Aspire-hosted integration suite): 1569/1569 + 13/13 passed, 0 failed. One known-flaky Aspire-suite test failed once and passed on the scoped retry.
• PublicAPI*.txt / CompatibilitySuppressions.xml: untouched (dependency-only change).

Backport to v1.0: no — v1.0 is advisory-only servicing; this is routine train alignment on main.

Note: why the Microsoft.Extensions.* entries stay literal

Consolidating them onto $(FrameworkVersion) was attempted and reverted: the Aspire 13.x client integrations shipped in src (Aspire.RabbitMQ.Client and the three EF provider integrations) floor Microsoft.Extensions.* at >= 10.0.8 on BOTH TFMs, so a 9.x net9.0 leg is an NU1605 downgrade error (reproduced on a full build). The constraint is now documented in Directory.Packages.props next to the pins.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.