Lite.Tests' cross-SKU source-scan pins run nowhere on a Mac: link them into Darling.Tests so every lane gets a local red, not a CI-first one (derivative of #3691) #3938

Derivative of #3691 lane 45 (#3881). Lite.Tests can't be built or run on macOS, because the project targets WPF. So its pure source-scan pins execute for the first time in CI's Windows build job, on every lane cut from a Mac. That is the recurring post-merge and pre-merge red this campaign has hit again and again.

The worst offenders are the cross-SKU surface pins:

• AlertReadFailureSurfaceTests.BothSkusToolDescriptions_StayByteIdentical, .EverySkusCollectionHealthTool_CarriesTheAlertReadBlock and .BothSkusBlocks_CarryTheIdenticalFieldSet_AndEveryFieldOfTheReading
• ServiceBuildSurfaceTests.EverySkusCollectionHealthTool_CarriesTheServiceBlock_WithTheIdenticalFieldSet

Each of these reads source text from BOTH SKUs' files and needs nothing from WPF. #3881 had to hand-verify two of them.

Shape:

• Move every Lite.Tests fact that is a pure source scan (no Lite type, no DuckDB, no WPF) into one file per class. Link that file into BOTH test projects with <Compile Include="…" Link="…" />, so there is one source of truth, Windows runs it in both, and Mac runs it in Darling.Tests.
• If the helpers or namespaces make linking unworkable, fall back to a Darling.Tests mirror, plus a census that the two copies assert identical strings.
• Fold in: Darling.Tests.csproj gains its missing explicit ProjectReference to PerformanceMonitor.Analysis (today it arrives transitively).

Test-infrastructure only. Not in any fence. Lane 49, claimed by pm-wave-worker.