Resolve dotnet for runtime-donor build when the SDK is under the user profile (fixes #90)

[Zaldaryon]

Problem

Issue #90 collects three failures from a v0.3.15 install. The csproj source/patch ownership conflict and the duplicated Optimum types (CS0433/CS0117) were already fixed on main in #99. This PR covers the remaining one, the runtime-donor packaging failure JimmyMac3 documented.

scripts/prepare-runtime-donors builds the exact runtime donors with a bare dotnet build, which uses whatever dotnet is on PATH. When the .NET SDK is installed under %USERPROFILE%\.dotnet (or ~/.dotnet) and that directory is not on PATH, the donor build fails with No .NET SDKs were found even though the main solution just built with that same SDK. The user's workaround was to set DOTNET_ROOT and PATH before launching the installer.

Root cause

The dotnet host discovers SDKs relative to the host executable's own location. A dotnet picked from PATH (or absent) does not see an SDK that lives under the user profile. The script already resolves ilspycmd with a PATH-then-profile fallback, but dotnet was left as a bare PATH lookup.

Fix

Resolve dotnet the same way the script resolves ilspycmd: prefer one on PATH, then fall back to the user-profile install. When the resolved dotnet lives in the profile install, set DOTNET_ROOT to that directory so the host discovers the SDK there. This matches Optimum.Bootstrap.Core/Acquisition/IlspycmdInstaller.cs, which already sets DOTNET_ROOT for the tool it spawns. Both donor builds use the resolved path. The change is mirrored in prepare-runtime-donors.sh for Linux and macOS.

Verification (Windows)

With dotnet on PATH, scripts/prepare-runtime-donors.ps1 runs end to end, builds VSEssentials and VSSurvivalMod, and prints Runtime donors ready under .build/runtime-donors with 0 build errors. With dotnet removed from PATH and only a ~/.dotnet install present (the reported environment), the resolver picks the profile dotnet and sets DOTNET_ROOT to ~/.dotnet. bash -n passes on the shell mirror.

Scope and risk

Two files, the packaging scripts only. No change to the ownership check, the patch pipeline, or the build itself. Behavior is unchanged when dotnet is already on PATH.

Fixes #90