Fail-fast 0xC000027B on machines with accumulated WindowsAppRuntime 1.8 revisions: activation fails with "Package not found" for the framework package the process is running from

## Describe the bug

Our WinUI 3 desktop app (unpackaged Win32/MFC host, XAML islands via `DesktopWindowXamlSource`, bootstrapped with `MddBootstrapInitialize2`) fail-fasts with `STATUS_STOWED_EXCEPTION` (0xC000027B) in Microsoft.UI.Xaml.dll on a subset of customer machines. On an affected machine the crash is **deterministic** — the same user action crashes every session — while machines that match on every observable dimension (same app binary, same framework revision, similar revision sprawl) never crash.

The failure fires on the **first lazy load of WinUI content in a session** (a ribbon page, a `Frame` navigation, a popup — whichever the user touches first). Debugging ~20 customer minidumps (`DirectUI::ErrorHelper::ProcessUnhandledError` → `errorInfo`), the central paradox is:

> `Package Microsoft.WindowsAppRuntime.1.8_8000.946.1701.0_x64__8wekyb3d8bbwe not found`

reported for **the very package the process is running from** — every runtime DLL in the module list is loaded from that package's WindowsApps directory, and only from it (no cross-revision mixing).

## Evidence from dump analysis

1. **Six distinct inner HRESULTs, one condition.** Across the debugged dumps the inner stowed error is one of: `0x80070490` (package not found, as above); `E_NOINTERFACE` from `ifactory->QueryInterface` (victims observed: `Microsoft.UI.Xaml.Controls.RadioButtons`, `Microsoft.UI.Xaml.Media.Animation.NavigationThemeTransition`); `HRESULT_FROM_WIN32(ERROR_KEY_DELETED)` (0x800703FA); `ERROR_INSUFFICIENT_BUFFER`; `E_INVALIDARG`; `ERROR_BAD_EXE_FORMAT`. Which one appears varies per launch **on the same machine**.

2. **Same machine, same action, alternating failure modes.** One machine produced four crashes in one day, all on the same user action: package-not-found at 08:19, a layout-cycle fail-fast (`0x802B0014`) at 12:22 and 13:42, package-not-found again at 14:19. A second machine produced `E_INVALIDARG` and `0x80070490` on the identical action 20 minutes apart. We read the layout cycles as secondary damage: a control activation fails non-fatally mid-layout and the half-built tree oscillates until the 250-pass limit.

3. **`ERROR_KEY_DELETED` pins the mechanism to registry-backed activation state.** One dump is a direct-shape fail-fast at first XAML island creation: `ActivationFactoryCache::GetCompositionEasingFunctionStatics` ← `DCompTreeHost::EnsureDCompDevice` ← `CXamlIslandRoot::InitializeCommon`, `__HR = HRESULT_FROM_WIN32(ERROR_KEY_DELETED)` — a read through a registry key deleted out from under the reader. This suggests per-user activation/registration state (ActivatableClasses / Appx repository) being deleted or rebuilt, and the activation path not being resilient to it.

4. **Affected machines carry accumulated framework revisions.** One affected machine has **eight** co-registered x64 `Microsoft.WindowsAppRuntime.1.8` framework revisions (8000.731.1532 → 8000.946.1701), all `Status: Ok` for the affected user. Its DDLM is 8000.675.1142.0 — older than all eight and Developer-signed (from the WindowsAppRuntimeInstall redistributable), while the frameworks are Store-signed: the Store serviced newer revisions on top without removing old ones. Another affected machine shows revisions split across user accounts.

5. **Failing servicing operations at crash time.** The AppXDeployment operational log of an affected machine shows recurring **Event 404: "AppX Deployment operation failed for package with error 0x80070490 Element not found" with an empty package name**, correlating with crash times — a machine-level deployment/cleanup operation failing repeatedly.

6. **Visible state does not discriminate.** A healthy machine matching the affected ones on every observable dimension (heavily sprawled: seven co-registered x64 1.8 revisions in the `Get-AppxPackage` view, same old Developer-signed DDLM, same binary, same framework revision) does not crash. On that machine the two views of registered revisions disagree: `Get-AppxPackage` for the user lists seven (8000.770 → 8000.946), while the user's SID key under `HKLM\...\Appx\AppxAllUserStore` lists six (8000.675 → 8000.946) — each view contains revisions absent from the other.

## Expected behavior

Either the activation path tolerates registration-state rewrites (retry/reopen on `ERROR_KEY_DELETED` instead of fail-fasting the process), or servicing never leaves per-user registration state in a condition where the hosting framework package cannot be resolved by the process running from it.

## Questions

1. Is this a known failure mode when WindowsAppRuntime framework revisions accumulate and servicing/cleanup operations fail repeatedly (the empty-package-name 0x80070490 Event 404s)?
2. Should `ActivationFactoryCache` / package-graph lookups be resilient to `ERROR_KEY_DELETED` and transient registration rewrites?
3. How can a package lookup return `ERROR_NOT_FOUND` for the package hosting the running process, and can that state be detected or repaired programmatically?
4. Is removing stale co-registered 1.8 revisions (`Remove-AppxPackage -AllUsers`, keeping the newest) a safe, supported cleanup? We are testing it as a customer workaround.

## Environment

- **Windows App SDK**: 1.8 (framework 8000.946.1701.0; also observed with 8000.921.1539.0), Microsoft.UI.Xaml.dll 3.1.8.0
- **App**: unpackaged Win32 desktop (MFC), WinUI 3 via XAML islands, `MddBootstrapInitialize2`
- **OS**: Windows 11 x64, builds 22631, 26100, 26200 (physical machines; VDI/roaming profiles ruled out)
- **Scale**: ~57 distinct devices across multiple unrelated organizations since June 2026; affected users crash-loop daily

## Additional context

The minidumps and event logs contain customer-identifiable data, so they are not attached here — we can share them through a private channel (or a Microsoft support case referencing this issue) on request.

Start with the ActivationFactoryCache and package-graph lookups described in the report, using MddBootstrapInitialize2 as the activation entry point. Correlate minidump inner HRESULTs with AppX Deployment Event 404 logs and accumulated framework revisions; done means establishing the supported failure mechanism and a defined resolution for transient registration rewrites or stale revisions.

Written by the indexing model from the issue text.