Swap the unmaintained MsBuildPipeLogger.Server/.Logger packages for the
single XenoAtom.MsBuildPipeLogger fork (1.0.1).

- Buildalyzer references the receiver API; logger DLL is bundled via the
  Buildalyzer.Logger package (excluded from the receiver ref).
- Buildalyzer.Logger compiles BuildalyzerLogger against the bundled logger
  assembly (shipped as copy-to-output content) and packs it alongside.
- Bump Microsoft.Build.Utilities.Core 14.3.0 -> 17.10.46 to match the
  logger's MSBuild version and the patched advisory (GHSA-w3q9-fxm7-j8fq).
- Adapt to the fork's nullable annotations; drop now-unneeded logger
  package refs from the test projects (DLL flows transitively).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…lyzer-pr-356

…sion mismatch

XenoAtom.MsBuildPipeLogger's receiver deserializes events with the real
Microsoft.Build BuildEventArgsReader, which must be at least as new as the
MSBuild that wrote them. Buildalyzer pinned Microsoft.Build 17.10.46 at runtime
while the SDK's MSBuild (18.6 on .NET 10) writes newer binlog records, so the
reader threw "unsupported type: 33" on every streamed build (19 failing tests).
Microsoft.Build 18.x only targets net10.0, so it can't simply be referenced from
Buildalyzer's net6.0/net8.0 targets.

Instead, follow XenoAtom's documented guidance: reference the Microsoft.Build.*
assemblies for compile only (ExcludeAssets=runtime, PrivateAssets=all) and load
the matching assemblies from the installed .NET SDK at runtime via
Microsoft.Build.Locator. The reader now always matches the SDK's writer,
verified against both .NET 10 (MSBuild 18.6) and .NET 11 preview (MSBuild 18.8).

- Add MSBuildLocatorBootstrap: a module initializer that registers
  MSBuildLocator before any Microsoft.Build type loads. It restores the
  MSBUILD_EXE_PATH/MSBuildExtensionsPath/MSBuildSDKsPath environment variables
  the locator sets, so they don't override BuildEnvironment's out-of-process
  build paths (which would redirect e.g. .NET Framework builds at the SDK).
- Centralize the compile-only MSBuild references in msbuild-references.props,
  imported by Buildalyzer and the test projects that use its MSBuild-typed API.
- Pin the last net6.0-capable Microsoft.Build.Locator (1.7.8) for net6.0; use
  1.11.2 for net8.0.
- Document the consumer-facing impact in RELEASE.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…turedLogger

With MSBuildLocator loading the SDK's MSBuild (18.6) in-process, AddBinaryLogger's
in-process BinaryLogger now writes binlog format v25 instead of the v18 that the
old pinned Microsoft.Build 17.10 produced. MSBuild.StructuredLogger 2.2.158 cannot
read v25 (it throws in ReadPropertyReassignmentEventArgs), so AnalyzerManager.Analyze
silently returned zero results — 19 GetsSourceFilesFromBinaryLog cases failed on CI
(SDK 10.0.302 / MSBuild 18.6.11), while passing locally on an older 18.6.4 patch.

Read the binary log with MSBuild's own BinaryLogReplayEventSource (loaded from the
SDK via MSBuildLocator) instead of MSBuild.StructuredLogger's BinLogReader. The reader
now always matches the SDK's MSBuild that wrote the log, exactly as the live pipe path
already does, removing the separately-versioned-reader mismatch entirely. This makes
MSBuild.StructuredLogger unused, so it is dropped.

Verified: full suite (231 tests) passes in a clean linux .NET 10.0.302 container
(MSBuild 18.6.11), reproducing the CI environment that exposed the failure.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>