fix(release): make MSBuild discovery resilient to newer VS lines

[cmxl]

Summary

release.ps1 fails on the discovery step with:

Cannot validate argument on parameter 'Name'.
The argument is null or empty.

The script relies on vswhere.exe to locate MSBuild. On machines where the bundled vswhere doesn't recognise the installed Visual Studio line, vswhere returns no output, $msBuildPath ends up null, and the next line — Get-Command $msBuildPath — raises the validation error above before anything else runs.

Environment that triggered this

I only installed Visual Studio Build Tools 2026 (and the .NET SDKs — note that the .NET SDKs do not ship an MSBuild compatible with the ClickOnce publish flow this script uses, so the .NET SDK MSBuild can't substitute for full MSBuild here).

Build Tools 2026 installs MSBuild at:

C:\Program Files (x86)\Microsoft Visual Studio\18\BuildTools\MSBuild\Current\Bin\MSBuild.exe

…and that binary works fine (msbuild -version → 18.6.3). The problem is purely discovery: the vswhere.exe shipped with the current VS Installer (v3.1.7, from 2023) predates VS 2026 (Dev18) and returns no output for it, so the script never finds the path.

Changes

release.ps1 — replaced the inline vswhere invocation with a Find-MSBuildPath function that:

• Tries vswhere first (existing behaviour preserved on machines where it works).
• Falls back to scanning known install paths:
  Microsoft Visual Studio\<ver>\<edition>\MSBuild\Current\Bin\MSBuild.exe
  for VS 17 / 18 / 2022 / 2026 across BuildTools / Community / Professional / Enterprise.
• Throws a clear error if neither approach finds MSBuild.

Testing

• Manually verified Find-MSBuildPath returns the Build Tools 2026 MSBuild on a machine where vswhere returns nothing.
• The resolved binary runs (msbuild -version → 18.6.3+84d3e95b4 for .NET Framework).
• No change to behaviour where vswhere does work — vswhere is still tried first and its result is used as-is.