Fix SDK detection treating ~/.dotnet cache as valid installation

[Copilot]

~/.dotnet typically contains cache/settings, not actual SDKs. Current detection checks it before system paths and only validates that a sdk/ subdirectory exists, causing incorrect path detection and missing SDK versions on macOS.

Changes

Path priority reordering

• System paths (/usr/local/share/dotnet, /usr/share/dotnet, /opt/homebrew/opt/dotnet/libexec) now checked before user directories
• Added /usr/share/dotnet and /usr/local/lib/dotnet to macOS paths
• ~/.dotnet moved to lowest priority (fallback only)

SDK validation

// Before: weak validation
if (Directory.Exists(path) && Directory.Exists(Path.Combine(path, "sdk")))
    return path;

// After: validates actual SDK presence
private bool IsValidSdkPath(string path)
{
    // Checks: path exists, sdk/ exists, contains version dirs, dotnet.dll present
    if (SdkVersion.TryParse(versionDir, out _))
        return File.Exists(Path.Combine(dir, "dotnet.dll"));
}

Supporting changes

• Added SdkVersion.TryParse() for safe version parsing (rejects "tools", "corefx", etc.)
• Debug logging throughout detection path (logs checked paths, rejection reasons, found SDKs)

Original prompt

The issue with MAUI.Sherpa involves incorrect detection of installed .NET SDK versions on macOS. Sherpa currently misinterprets the ~/.dotnet directory as an SDK location, which often doesn't point to valid SDK installations. This results in the tool showing incorrect or missing SDK versions, as reported in issue #36.

To address this:

1. Update SDK detection logic to exclude ~/.dotnet as a presumed SDK location unless specific subdirectories (like ~/.dotnet/sdk) explicitly contain valid SDK installations.
2. Ensure that detecting SDK versions considers paths commonly used for installations, such as /usr/local/share/dotnet, /usr/local/lib/dotnet, or other relevant paths for macOS.
3. Add robust validation checks to confirm SDK integrity from detected paths.
4. Include additional debugging logs for better insights into how and where SDKs are identified.

Implement these changes in the codebase, test extensively on macOS environments similar to those mentioned in the GitHub issue, and verify that the issue is resolved.

This pull request was created from Copilot chat.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Redth]

I've rebased this on main and reworked the path resolution to follow the official dotnet/designs install-locations spec.

What changed from the original PR

Added: /etc/dotnet/install_location file support (macOS/Linux)
This is the official registered install location mechanism. The .pkg installer writes these files:

• /etc/dotnet/install_location_arm64 → e.g. /usr/local/share/dotnet
• /etc/dotnet/install_location → e.g. /usr/local/share/dotnet/x64

These are more reliable than hardcoding paths — they tell us exactly where the installer put things.

Added: Per-architecture install_location_<arch> files (.NET 6+)
Supports x64/arm64 side-by-side on Apple Silicon Macs.

Added: Windows registry lookup
HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\<arch>\InstallLocation — the official mechanism for custom global installs on Windows.

Added: /usr/local/share/dotnet/x64
The x64-on-arm64 macOS path (Rosetta). Confirmed present on real systems.

Removed: incorrect paths

• /usr/share/dotnet on macOS — this is a Linux path, not macOS
• /usr/local/lib/dotnet — not a standard path on any platform

Kept from original PR:

• IsValidSdkPath() with dotnet.dll validation ✅
• SdkVersion.TryParse() ✅
• Debug logging throughout ✅
• ~/.dotnet as lowest priority ✅
• SdkVersion.TryParse tests ✅

Full resolution order now

1. DOTNET_ROOT_<ARCH> / DOTNET_ROOT env vars
2. /etc/dotnet/install_location_<arch> (macOS/Linux)
3. /etc/dotnet/install_location (macOS/Linux)
4. Windows registry InstallLocation key
5. Default global paths (/usr/local/share/dotnet, %ProgramFiles%\dotnet, etc.)
6. Additional well-known paths (x64-on-arm, Homebrew, VS private install)
7. Project-local .dotnet
8. ~/.dotnet (lowest priority — usually just cache/settings)

All 135 tests pass (88 Core + 47 Workloads). Mac Catalyst build succeeds.