Standard users cannot launch WinAppSDK apps: Singleton package Access Denied (0x80070005)

### Describe the bug

An MSIX packaged application built with WinAppSDK fails to launch when executed by a standard, low-privileged user. The application only launches successfully if it is explicitly run as an administrator.

Troubleshooting revealed that this issue is tied to the `Microsoft.WindowsAppRuntime.Singleton` package. Event logs show access denied errors (0x80070005) related to the provisioning of `MicrosoftCorporationII.WinAppRuntime.Singleton` for the standard user. The installation/update process does not fail outright, but permission management is corrupted, preventing the app from starting for non-admins.

When attempting to install or provision the application as a standard user, the Appx deployment server logs record the following errors:

```text
AppX Deployment operation failed for package __x64__ with error 0x80070005. The specific error text for this failure is: Deployment operation failed.
```

```text
Started deployment Add operation on a package with main parameter .msix and Options ForceApplicationShutdownOption,ForceTargetApplicationShutdownOption,ForceUpdateFromAnyVersion,NormalPriorityRequest and 0. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.
```

Additionally, there is a specific warning related to the WinAppRuntime Singleton package not finding user-specific files:

```text
MicrosoftCorporationII.WinAppRuntime.Singleton_8000.879.2017.0_x64__8wekyb3d8bbwe : C:\Program Files\WindowsApps\MicrosoftCorporationII.WinAppRuntime.Singleton_8000.879.2017.0_x64__8wekyb3d8bbwe\microsoft.system.package.metadata\S-1-5-21-[Redacted_User_SID]-1002-MergedResources-*.pri : No user-specific merged files found
```

**AppXSVC Queue Jamming:**
Further investigation of the Event Viewer revealed Information and Warning logs showing that the `AppXSvc` (Deployment Service) fails to clear out older packages due to locked files (e.g., throwing a `0x5` Access Denied error when trying to delete files in `C:\Program Files\WindowsApps\Deleted`). Because the deployment service cannot process the locked files, the queue jams, causing subsequent MSIX deployments (like the WinAppRuntime Singleton) to fail their permission management processes.

### Steps to reproduce the bug

**Note:** We have not found a way to reproduce this issue locally. It occurs intermittently in specific client environments, making it difficult to reproduce on demand.

1. Deploy an MSIX packaged application built with WinAppSDK 1.8 (or newer) via Intune or the Microsoft Store.
2. Log into Windows with a standard, non-administrator user account.
3. Attempt to launch the application normally.
4. The application briefly attempts to start and immediately closes without opening the UI.
5. Right-click the application and select "Run as administrator" – the application successfully launches.

### Expected behavior

The application and its associated WinAppSDK runtime components should provision correctly and launch for standard users without requiring elevated administrator privileges.

### Screenshots

_No response_

### NuGet package version

1.8.260209005

### Packaging type

Packaged (MSIX)

### Windows version

Windows 11 version 24H2 (26100, June 2025 Update)

### IDE

Visual Studio 2022, Other

### Additional context

* **The issue persists even if we try to install the app using the latest version of the WinAppSDK (version 2.3.1).**
* The issue persists even if the `C:\Program Files\WindowsApps\Deleted` directory is forcibly cleared and AppXSvc is restarted.
* WinUI 3 Gallery installed from the Microsoft Store exhibits the exact same behavior on affected machines (installs successfully but fails to run as a standard user).

## Workarounds Discovered
Our team found two ways to bypass or fix this issue:

**Workaround 1: Manual Singleton Provisioning**
Downloading the `Microsoft.WindowsAppRuntime.Singleton.msix` (from the 1.8 redistributable) and forcing a manual provision via PowerShell for the low-privileged user restores functionality:
```powershell
Add-AppxProvisionedPackage -Online -PackagePath "C:\Path\To\Singleton.msix" -SkipLicense
Add-AppxPackage -RegisterByFamilyName -MainPackage "MicrosoftCorporationII.WinAppRuntime.Singleton_8wekyb3d8bbwe"
```

**Workaround 2: Downgrading WinAppSDK**
Downgrading our project's WinAppSDK version from `1.8.260209005` back to `1.7.250401001` completely resolves the issue.

Start with the AppXSvc Event Viewer deployment logs and the 0x80070005 failures involving the WinAppRuntime Singleton and locked files under WindowsApps\Deleted. Compare affected standard-user launches with WinAppSDK 1.8 and 1.7, and verify whether manual Singleton provisioning changes the result. Done means a packaged app launches normally for a standard user without elevation.

Written by the indexing model from the issue text.