Isolate child dotnet commands from unsafe MSBuild state

[OvesN]

Summary

• refine Handle CryptoKeyFile from SolutionReader #375's blanket MSBuild* environment removal to a three-variable denylist
• remove the two SDK-identifying paths that can mix parent targets/tasks with child MSBuild assemblies
• preserve Handle CryptoKeyFile from SolutionReader #375's stdout-handle fix by removing MSBUILDENSURESTDOUTFORTASKPROCESSES
• preserve platform-specific environment-name semantics and legitimate unrelated MSBuild settings
• route exported-solution builds through the isolated launcher with the export directory as the working directory

Root cause

The .NET CLI sets MSBuildExtensionsPath and MSBuildSDKsPath for its selected SDK. A child dotnet command can select a different SDK based on its working directory and global.json roll-forward policy.

Inheriting those paths can combine targets and NuGet.Build.Tasks.dll from the parent SDK with Microsoft.Build.Framework from the child SDK. The mismatch became visible when newer NuGet tasks began implementing IMultiThreadableTask, producing MSB4062 type-load failures.

MSBUILDENSURESTDOUTFORTASKPROCESSES is a separate hazard: reusable MSBuild worker nodes inherit the redirected stdout handle, while ProcessUtil synchronously waits for stdout EOF. Removing it preserves the subprocess-hang fix introduced by #375.

The .NET 10.0.400 SDK bundle itself was verified to contain a matching Microsoft.Build.Framework; the type-load failure is caused by cross-SDK environment contamination rather than an inconsistent bundle.

Why an explicit denylist

PR #375 removed every variable beginning with MSBuild. This follow-up retains that fix's known unsafe variables while preserving unrelated MSBuild configuration such as MSBuildLoadMicrosoftTargetsReadOnly and MSBuildExtensionsPath32/MSBuildExtensionsPath64.

The denylist is intentionally explicit. Future SDK-injected variables that identify a parent SDK or alter redirected process lifetime should be evaluated and added when necessary.

Compatibility

This changes only internal process-launch behavior and restores the existing intent that child dotnet commands select a coherent SDK context. DOTNET_HOST_PATH remains preserved because it identifies the shared muxer.

Validation

• dotnet build Basic.CompilerLog.slnx -warnaserror
• focused net10.0 run covering SolutionReaderTests.CryptoKeyFile and every changed solution-build launch path: 22 passed, Unix-only environment-casing test skipped on Windows
• focused net472 regression test