Windows MSI workload-set install state retains stale manifest pins after Visual Studio servicing

### Describe the bug

On Windows x64 with .NET SDK `10.0.400` and Visual Studio Community 2026 `18.9.2` (`18.9.12120.119`), workload-set mode reports workload version `10.0.400`, but six active first-party manifests remain pinned to older versions.

The system install-state file for feature band `10.0.400` has `useWorkloadSets: true` and `workloadVersion: 10.0.400`, while its `manifests` object explicitly selects the six older versions. Each selected version exactly matches `dotnet --info` and differs from the published workload-set `10.0.400` mapping. An unpinned macOS manifest resolves to the newer mapped version, providing control evidence for the override behavior.

Visual Studio mobile components were removed and reinstalled through Visual Studio Installer, the older Visual Studio 2022 instance was normally uninstalled, and Visual Studio 2026 servicing completed successfully. The stale selections remained active.

### Steps to reproduce

This is a stateful Windows MSI/Visual Studio ownership issue rather than a clean-machine minimal reproduction. The observed sequence was:

1. The system-wide .NET installation had historical workload changes from both the .NET CLI and Visual Studio Installer.
2. Visual Studio Community 2022 and Visual Studio Community 2026 had both contributed mobile workload ownership.
3. The CLI-owned `maui` workload registration was removed using the selected SDK.
4. Visual Studio Community 2022 was normally uninstalled.
5. Mobile workload ownership was removed from Visual Studio Community 2026 and restored through Visual Studio Installer.
6. Visual Studio Community 2026 was updated to `18.9.2`.
7. Read-only verification was run with `dotnet --info`, `dotnet workload config --update-mode`, `dotnet workload --version`, `dotnet workload list`, and `dotnet workload history`.
8. The feature-band install-state `default.json` was read without modification and correlated with active manifest selection.

No direct MSI removal, registry editing, manifest-directory deletion, `default.json` editing, or CLI repair/update/install was performed during this diagnosis.

### Expected behavior

When workload-set mode selects `10.0.400` after successful Visual Studio Installer servicing, active first-party manifest versions should agree with the published `10.0.400` workload-set mapping, or servicing should reconcile obsolete install-state overrides while preserving valid Visual Studio ownership.

| Manifest | Expected published `10.0.400` version |
|---|---|
| Android | `36.1.69/10.0.100` |
| iOS | `26.5.10301/10.0.100` |
| Mac Catalyst | `26.5.10301/10.0.100` |
| tvOS | `26.5.10301/10.0.100` |
| MAUI | `10.0.20/10.0.100` |
| Mono toolchain current | `10.0.111/10.0.100` |

### Actual behavior

The selected workload set is loaded, but the feature-band install-state manifest entries replace the matching workload-set entries. The active tuple is:

| Manifest | Install-state pin and active version | Published `10.0.400` version |
|---|---|---|
| Android | `36.1.2/10.0.100` | `36.1.69/10.0.100` |
| iOS | `26.1.10502/10.0.100` | `26.5.10301/10.0.100` |
| Mac Catalyst | `26.1.10502/10.0.100` | `26.5.10301/10.0.100` |
| tvOS | `26.1.10502/10.0.100` | `26.5.10301/10.0.100` |
| MAUI | `10.0.1/10.0.100` | `10.0.20/10.0.100` |
| Mono toolchain current | `10.0.101/10.0.100` | `10.0.111/10.0.100` |

The unpinned `microsoft.net.sdk.macos` manifest resolves to `26.5.10301/10.0.100`. Visual Studio Community 2026 reports complete, launchable, and no reboot required. Twelve MSI registrations remain across the six affected manifest families, representing older and newer side-by-side registrations.

The install-state file is 434 bytes, was last modified `2026-08-25T15:14:59-04:00`, and has SHA-256 `3EC9342928F3D4BDF6F5AEBF2C35BCEA335B514370594A6FFBEA427B421E3E64`.

### Is this a regression?

The machine previously had a validated mobile toolchain, but the precise point at which these six install-state pins became stale is not known. The failure persisted after removing the older Visual Studio owner and reinstalling mobile components through the retained Visual Studio Installer.

### Are there any workarounds?

No accepted workaround is being used. Manual install-state edits, direct MSI removal, registry edits, manifest deletion, and additional CLI workload mutation were intentionally avoided because the system-wide installation is Visual Studio-managed and the required ownership-safe reconciliation procedure is unknown.

### dotnet --info output

```console
.NET SDK:
Version: 10.0.400
Commit: 14fbf8d527
Workload version: 10.0.400
MSBuild version: 18.9.6+14fbf8d52

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26200
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\10.0.400\

.NET workloads installed:
[android]
Installation Source: SDK 10.0.400, VS 18.9.12120.119
Manifest Version: 36.1.2/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.android\36.1.2\WorkloadManifest.json
Install Type: Msi

[ios]
Installation Source: SDK 10.0.400, VS 18.9.12120.119
Manifest Version: 26.1.10502/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.ios\26.1.10502\WorkloadManifest.json
Install Type: Msi

[maccatalyst]
Installation Source: SDK 10.0.400, VS 18.9.12120.119
Manifest Version: 26.1.10502/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maccatalyst\26.1.10502\WorkloadManifest.json
Install Type: Msi

[maui-windows]
Installation Source: SDK 10.0.400, VS 18.9.12120.119
Manifest Version: 10.0.1/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maui\10.0.1\WorkloadManifest.json
Install Type: Msi

[tvos]
Installation Source: SDK 10.0.400
Manifest Version: 26.1.10502/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.tvos\26.1.10502\WorkloadManifest.json
Install Type: Msi

[wasm-tools]
Installation Source: SDK 10.0.400, VS 18.9.12120.119
Manifest Version: 10.0.101/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.current\10.0.101\WorkloadManifest.json
Install Type: Msi

[wasm-tools-net8]
Installation Source: SDK 10.0.400
Manifest Version: 10.0.111/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.net8\10.0.111\WorkloadManifest.json
Install Type: Msi

Configured to use workload sets when installing new manifests.

Host:
Version: 10.0.11
Architecture: x64
Commit: e2f47b0110

.NET SDKs installed:
10.0.100-rc.1.25451.107 [C:\Program Files\dotnet\sdk]
10.0.400 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.30 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
\global.json

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download
```

### IDE version

Visual Studio Community 2026 `18.9.2` (`18.9.12120.119`).

### Other details

Resolver behavior was correlated with `SdkDirectoryWorkloadManifestProvider`: workload-set manifests are loaded, then install-state manifest entries with matching IDs replace those entries when install-state manifest use is enabled.

Related precedent: `dotnet/sdk#52090` requested a new issue with complete Windows MSI details when this failure class occurs with Windows admin/MSI installs.

### Questions for the workload team

1. Which installer or workload operation is expected to remove or update these first-party manifest pins after Visual Studio servicing?
2. Why did successful Visual Studio mobile-component removal/reinstallation and subsequent Visual Studio servicing leave the stale feature-band pins active?
3. What Microsoft-supported procedure safely reconciles this mixed historical CLI/Visual Studio MSI state while returning the system-wide root to Visual Studio Installer ownership?
4. Should Visual Studio Repair be expected to reconcile this install state, or would it only reinstall already-registered packages?
5. Which additional Installer, MSI, or workload diagnostic logs would help identify the operation that retained or skipped cleanup of these pins?

### Sanitized attachments (provided in Microsoft-Workload-Escalation-Evidence-20260901.zip)

- `attachments/sdk/dotnet-info-after-sanitized.txt`
- `attachments/sdk/active-manifests-after-corrected.txt`
- `attachments/sdk/workload-mode-after.txt`
- `attachments/sdk/workload-version-after.txt`
- `attachments/sdk/workload-list-after.txt`
- `attachments/sdk/workload-history-after.txt`
- `attachments/sdk/install-state-default-sanitized.json`
- `attachments/sdk/install-state-default-metadata.txt`
- `attachments/visual-studio-msi/visual-studio-2026-status.json`
- `attachments/visual-studio-msi/visual-studio-2026-mobile-components.json`
- `attachments/visual-studio-msi/affected-manifest-msi-registrations.csv`

[Microsoft-Workload-Escalation-Evidence-20260901.zip](https://github.com/user-attachments/files/31701955/Microsoft-Workload-Escalation-Evidence-20260901.zip)

Start with SdkDirectoryWorkloadManifestProvider and the feature-band install-state default.json described in the report, then review the supplied sanitized workload and Visual Studio MSI evidence. Trace which installer or workload operation handles manifest pins after servicing and determine what supported reconciliation should preserve Visual Studio ownership. Use the requested Installer, MSI, and workload diagnostic logs to establish the cleanup path and expected behavior.

Written by the indexing model from the issue text.