Validate MSBuild server in VMR validation pipeline

[AR-May]

1. Run the VMR validation pipeline with MSBuild server enabled and identify issues beyond the known restore task limitation.
2. Resolve the identified issues
3. Switch the VMR validation pipeline to use MSBuild server by default.

[JanProvaznik]

Cross-referencing the broader MSBuild Server default-on analysis at #9379 (overnight investigation summary).

This issue is Infrastructure — direct tracking issue for the VMR fsharp TimeoutException in pipeline 20260428.5.

Two compounding root causes confirmed:

1. Apphost / DOTNET_ROOT propagation (primary cause, .NET 10.0.300 regression introduced by PR Add App Host Support for MSBuild #13175): MSBuildClient.TryLaunchServer invokes NodeLauncher.Start without EnvironmentOverrides, so the launched server child (which is the apphost .exe after Add App Host Support for MSBuild #13175) cannot find the .NET runtime — server never opens its named pipe, client times out. Already fixed by PR #13716 (open, co-authored by @rainersigwald + @JanProvaznik). Adds DotnetHostEnvironmentHelper.CreateDotnetRootEnvironmentOverrides() to the launch.

2. Pipe-recycling race + uncaught exception (secondary cause, predates apphost): TryConnectToPipeStream at NodeProviderOutOfProcBase.cs:804 propagates TimeoutException uncaught past MSBuildClientApp.Execute — when the server is briefly unavailable mid-BuildCompleteReuse cycle (running mutex held, pipe being recycled, busy mutex released → client probes "hot server" and tries 1 s connect), the timeout becomes a crash rather than graceful in-proc fallback. PR Fix TimeoutException when DOTNET_CLI_USE_MSBUILD_SERVER=true on .NET 10.0.300 #13716 also adds a caller-level catch in TryConnectToServer that mitigates this. A complementary callee-level catch inside TryConnectToPipeStream provides defense-in-depth for any future caller (prototype branch, pending PR).

Structural contributor: within each VMR vertical all repos share the same ServerNodeHandshake pipe name (same .dotnet tools dir, no per-repo TMPDIR differentiation; PR #13651 to add Path.GetTempPath() to the salt was closed as "too heavy"). The immediate zero-code-change VMR fix is MSBUILDNODEHANDSHAKESALT=$(RepositoryName) per repo <Exec> in repo-projects/Directory.Build.targets — also makes dotnet build-server shutdown --msbuild from CleanupRepo more meaningful.

Prerequisites for switching VMR validation to server-by-default:
(a) PR #13716 merged (apphost + caller-level resilience)
(b) PR #13660 merged (RestoreTask transient TaskHost)
(c) Per-repo MSBUILDNODEHANDSHAKESALT in VMR's Directory.Build.targets