Visual Studio updates override custom .NET SDK PATH configuration

### Describe the bug

**Visual Studio updates silently re-add C:\Program Files\dotnet\ to System PATH, overriding custom DOTNET_ROOT configuration**

**Area:** Visual Studio Installer / .NET SDK / Environment Configuration

**Type:** Bug / Unexpected Behavior

**Description:**

When a developer configures a custom .NET SDK installation path (e.g., E:\DotNet) by setting DOTNET_ROOT and adjusting the system PATH variable, Visual Studio updates silently re-add C:\Program Files\dotnet\ to the System PATH — overriding the developer's configuration without any warning or consent.

### Steps to reproduce

Install .NET SDK to a custom directory (e.g., E:\DotNet).
Set DOTNET_ROOT environment variable to E:\DotNet (both System and User level).
Add E:\DotNet to User PATH.
Remove C:\Program Files\dotnet\ from System PATH.
Verify dotnet --version resolves to E:\DotNet\dotnet.exe — ✅ works correctly.
Update Visual Studio (or let it auto-update).
Open a new terminal and run where dotnet.
Actual behavior:

C:\Program Files\dotnet\ is silently re-added to the System PATH at a higher priority than the User PATH.
dotnet.exe now resolves to C:\Program Files\dotnet\dotnet.exe instead of the developer's custom path.
DOTNET_ROOT still points to E:\DotNet, creating a mismatch between the running SDK and the configured root.
This mismatch causes workload installation failures with MSI errors like:

Failed to repair .msi. Error: 0x0000064c
"Installation source for this product is not available"
The developer is unaware of this change until builds start failing.
Expected behavior:

Visual Studio should detect and respect an existing DOTNET_ROOT environment variable.
If DOTNET_ROOT is set to a non-default path, VS should not add C:\Program Files\dotnet\ to the System PATH.
At minimum, VS should warn the developer that it is modifying the System PATH and potentially conflicting with their custom configuration.
Ideally, VS should use the SDK pointed to by DOTNET_ROOT rather than installing a parallel copy.
Impact:

Workload corruption: MSI installers get confused between two SDK installations, leading to failed installs, repairs, and updates.
Silent breakage: The developer's environment breaks silently after a VS update. Builds that previously worked start failing with cryptic MSI errors.
Wasted time: Diagnosing the root cause (PATH priority change) is non-obvious and can waste hours of developer time.
Recurring issue: Every VS update re-introduces the problem, making it a persistent maintenance burden.
Environment:

Visual Studio 2026 (v18.7)
.NET SDK 10.0.301 (auto-installed by VS to C:\Program Files\dotnet$
.NET SDK 9.0.315 (manually installed to E:\DotNet)
DOTNET_ROOT = E:\DotNet
Windows 10

### Expected behavior

**Respect DOTNET_ROOT:** If DOTNET_ROOT is set, do not modify the System PATH to include a different dotnet path.
Prompt before modifying PATH: Show a dialog during VS update: "We detected a custom .NET SDK configuration. Would you like to keep your current setup or switch to the Visual Studio-managed SDK?"
Add a VS setting: Allow developers to opt out of automatic .NET SDK PATH management in VS installer settings.
Use DOTNET_ROOT for workloads: Ensure dotnet workload commands respect DOTNET_ROOT and install workloads to the correct SDK location.

### Actual behavior

After updating Visual Studio, `C:\Program Files\dotnet\` is silently re-added to the System PATH at a higher priority than the User PATH entry (`E:\DotNet`).
Since System PATH is evaluated before User PATH, `dotnet.exe` now resolves to `C:\Program Files\dotnet\dotnet.exe` instead of the developer's custom path (`E:\DotNet\dotnet.exe`).
This creates a mismatch: `DOTNET_ROOT` points to `E:\DotNet` but the running SDK is from `C:\Program Files\dotnet\`.
As a result, workload operations fail with MSI errors:

### Is this a regression?

Yes. This worked correctly in earlier versions of Visual Studio (2022). The System PATH was not overwritten when DOTNET_ROOT was already configured. The issue started occurring with Visual Studio 2026 updates.

### Are there any workarounds?

Yes, but they are manual and must be repeated after every VS update: or windows update
1. Open System Environment Variables
2. Edit System PATH → Remove "C:\Program Files\dotnet\"
3. Restart all terminals and Visual Studio
This workaround is fragile — every Visual Studio update silently re-adds the entry, breaking the environment again.

### dotnet --info output

```console

```

### IDE version

Visual Studio 2026 (v18.7)

### Other details

_No response_

Start by reproducing the Visual Studio update with DOTNET_ROOT set to E:\DotNet, then inspect the resulting System PATH and `where dotnet` output. Compare the selected SDK with `dotnet --info` and determine which Visual Studio or SDK installation component changes PATH; done means custom configuration is preserved or a clear conflict warning and supported behavior are established.

Written by the indexing model from the issue text.