Docs refresh for .NET 10, and make the interceptor goldens run outside Windows

[mgravell]

Three tidies that turned up while re-reading the docs after a break. Separate commits; the middle one is a 100-file mechanical re-spelling, so it reads best commit-by-commit.

Docs: refresh for .NET 10 (ec6723c)

The getting-started transcripts were captured on the .NET 8 SDK and had aged out of accuracy - all re-captured against 10.0.302:

• the MSBuild version 17.8.3+195e7f5a3 for .NET banner is no longer printed;
• CS9137 no longer calls interceptors an experimental feature;
• the generated-file path in that error was missing its obj\Debug\<tfm> segment;
• sample output said net8.0, where UsageLinker has targeted net10.0 for a while.

The part worth a look. #215 moved the docs to InterceptorsNamespaces, which is right for current SDKs but only half the story - the .NET 8 SDK, which this page names as the minimum, understands only InterceptorsPreviewNamespaces, and neither SDK knows the other's name:

SDK	InterceptorsPreviewNamespaces	InterceptorsNamespaces	both
8.0.423	✅	❌ CS9137	✅
10.0.302	✅	✅	✅

Both are now shown in one annotated snippet, with a FAQ entry for the symptom, since CS9137 is what people actually arrive with. UsageLinker and Dapper.AOT.Test set only the older name; they now set both, as UsageBenchmark already did.

Also: a PublishAot section (the page never mentioned it, despite that being the point); the limitations section now points at declarative type handlers rather than a flat "configuration is not used"; the FAQ's QueryMultiple answer no longer implies it is supported, since it is refused and diagnosed; EmitCompilerGeneratedFiles offered for viewing generated code outside VS; and two bulk-copy fixes - the MS Learn link pointed at legacy System.Data.SqlClient, and the ColumnMappings sample was missing a comma, so it would not compile.

Tests: goldens are OS-neutral (1450fa4)

Tests find their inputs with Directory.GetFiles, and that path is baked into the emitted [InterceptsLocation(...)] - so the goldens carried whatever separator wrote them. All 49 interceptor golden tests failed on Linux; nobody had noticed, because nobody had run them there.

RoslynTestHelpers.CreateCompilation now normalizes to / before it reaches the compilation - which is what GeneratorTestBase already did for the .output.txt diagnostics side ("need to normalize paths"); the code-golden side was simply the half that got missed.

Two spots that are easy to miss: IncludeSqlSource also embeds the path in a SQL comment, so its netfx golden needed it too; and SqliteUsage.snapshot.cs is deliberately untouched, being a real interceptor compiled into the test assembly whose InterceptsLocation is the /_/ deterministic path.

Tests: golden write-back actually works now (52b6022)

InterceptorTests writes .output.cs back to source "for git tracking", but located the source folder via [CallerFilePath], which DeterministicSourcePaths maps to /_/test/.... The write failed on every OS, silently - the exception is caught and logged, so the only symptom was a "Could not find a part of the path" line and a golden that never updated. notes/harness-baseline.md carried a manual workaround for this.

GeneratorTestBase.ProjectFolder walks up from the test binaries to find the project file instead: determinism intact, no absolute paths baked into the assembly, and null off a working tree so CI doesn't write.

Verification

net8.0 376/376 and net10.0 376/376, both from 327/376. A run leaves the working tree unchanged, which also confirms the two legs agree on the shared goldens. The note records the gotcha that cost me a confusing diagnosis: the expected side is read from the copy in bin, so after a golden changes you need a build before the next run agrees with it.

net48 cannot run here and wants a Windows check - its goldens got the identical mechanical treatment, and normalization happens before the generator sees anything so the TFM is irrelevant to the path string, but it is unverified.