build: migrate from .NET 9 to .NET 10 (LTS)

[sundaramramaswamy]

What

Migrate the entire repo from .NET 9 to .NET 10 (LTS) as suggested by @codemonkeychris — rolling forward to the current LTS release rather than staying on .NET 9 (STS, EOL May 2026).

Why .NET 10 instead of .NET 9?

• .NET 9 is STS — standard support ends May 2026; we'd be shipping on an end-of-life runtime almost immediately.
• .NET 10 is LTS — long-term support until November 2028; aligns with production stability expectations.
• CI runners already have .NET 10 — windows-latest ships with 10.0 SDK pre-installed; without a global.json pin, builds were already silently picking it up.
• Windows App SDK 2.0.1 supports .NET 10 — no blocking compatibility issues.

Changes

SDK & TFM (101 projects)

• All csproj files: net9.0-windows10.0.22621.0 → net10.0-windows10.0.22621.0 (5 samples were already on net10.0)
• Added global.json pinning SDK to 10.0.100 with latestFeature roll-forward

CI Workflows

• ci.yml, coverage.yml, release.yml: dotnet-version: 9.0.x → 10.0.x
• Coverage and release artifact paths updated for net10.0 TFM

C# 14 Compatibility

• ValidationContext.cs: renamed field → fieldName in tuple deconstructions inside a property getter (field is a keyword in C# 14)

Documentation & Templates

• README, CONTRIBUTING, SKILL.md: prerequisites and examples updated to .NET 10
• Doc pipeline templates (getting-started.md.dt, readme.md.dt) and compiled guides updated
• ai-author-skill.md, 013-doc-system-design.md: prerequisite references updated

Test Infrastructure & Benchmarks

• TestSession.cs, WinFormsTestSession.cs, SelfTestBatch.cs: hardcoded TFM paths updated
• CLI scaffolder template TFM updated
• All benchmark/perf scripts updated

Bug Fix (drive-by)

• SKILL.md: corrected ProjectReference path (..\Reactor\ → ..\src\Reactor\)

Verification

• Build: 0 errors ✅
• Unit tests: 6790 passed, 3 locale-specific failures (pre-existing on main, locale PR forthcoming)
• Selftests: ~650 passed, 1 FlexInBorder_MainAxisDistributed (pre-existing on main)

[sundaramramaswamy]

CI: Build/Tests skipped (docs-only change detected). Pack pending. Local verification: unit tests (6790 passed, 3 pre-existing failures), selftests (638 passed, 1 pre-existing failure).

[codemonkeychris]

Why did you select .NET 9 instead of .NET 10 to pin to? any reason to stick with older, or should we roll forward?

[codemonkeychris]

CI: Build/Tests skipped (docs-only change detected). Pack pending. Local verification: unit tests (6790 passed, 3 pre-existing failures), selftests (638 passed, 1 pre-existing failure). Note: global.json commit was dropped — it broke CI because some samples target net10.0 and CI only installs .NET 9. Ready for merge.

there aren't any preexisting failures. i'm still tracking down some flake tests (should be around 92% reliable). If the tests pass on re-run, it's flakey - don't bother tracking it down, I have a multi-hour stress run trying to track down the flakey tests. if it doesn't pass on re-run, it's a regression

[sundaramramaswamy]

Why did you select .NET 9 instead of .NET 10 to pin to? any reason to stick with older, or should we roll forward?

As in the PR description most important projects used 9, hence 9.:

• Core framework (src/): all net9.0 (3 projects)
• Tests (tests/): all net9.0 (~50 projects)
• CI (ci.yml): installs dotnet 9.0.x

dotnet 10.x is preferrable as it's LTS. Refer https://versionsof.net/core/.

[codemonkeychris]

Weird - i see the comment history saying you've updated to .NET 10, but the commits in the PR still only show the .NET 9 version?? is that a github bug or... ?

[sundaramramaswamy]

@codemonkeychris Thanks for the clarification on flaky tests.

While investigating, I discovered 3 locale-specific test failures that reproduce consistently on machines with non-US locales (e.g. en-IN). They pass on CI because windows-latest runners use en-US:

1. FormatNumber_Default_UsesLocaleFormatting — expects 1,234.56 but gets 1,234.560. The en-US NumberDecimalDigits is 3 on current .NET/ICU versions, but the test hardcodes 2.

2. FormatNumber_Percent_FormatsPercent — same root cause: PercentDecimalDigits is 3, test expects 2 decimal places (75.00% vs 75.000%).

3. FormatDefaultLabel_Large_Number_Uses_Grouping — expects 1,234,567 but gets 12,34,567. This is a production bug: ChartPointProvider.FormatYValue() calls ToString("N0") without specifying CultureInfo, so it picks up the thread's current culture. Indian English uses lakh/crore grouping (12,34,567) instead of the Western 1,234,567.

All 3 reproduce identically on unmodified main — they're not regressions from this PR. I'll raise a separate PR with fixes shortly.

[sundaramramaswamy]

Weird - i see the comment history saying you've updated to .NET 10, but the commits in the PR still only show the .NET 9 version?? is that a github bug or... ?

Looks like copilot was awaiting my approval. Tests succeeded so I merged it.