Installation of apps should be blocked when required OS servicing updates are missing

Nobody has claimed this yet.

### Describe the bug

Windows App SDK apps requiring elevation can be installed on systems missing required OS servicing updates, leading to silent failures at runtime instead of blocking installation. Let's establish the real scenario where I encountered the issue. I have an app that requires elevation all the time in order to run, so it will always prompt the user to allow that once it's launched. On some machines that was not happening, as the app would silently fail with a generic error like this:

```
Faulting application name: app.exe, version: 1.0.0.0, time stamp: 0x68760000
Faulting module name: KERNELBASE.dll, version: 10.0.19041.1202, time stamp: 0xc9db1934
```

The reason is the following:

> Elevated support requires the following OS servicing update:
> - Win11 - [May 10, 2022—KB5013943 (OS Build 22000.675)](https://support.microsoft.com/topic/may-10-2022-kb5013943-os-build-22000-675-14aa767a-aa87-414e-8491-b6e845541755)
> - Win10 - [May 10, 2022—KB5013942 (OS Builds 19042.1706, 19043.1706, and 19044.1706)](https://support.microsoft.com/topic/may-10-2022-kb5013942-os-builds-19042-1706-19043-1706-and-19044-1706-60b51119-85be-4a34-9e21-8954f6749504)

Windows App SDK, as of version **1.1** when elevation support was introduced works **only if these updates are installed.**

The first instinct was to specify the servicing update in the `MinVersion` attribute of `TargetDeviceFamily` element:

```XML

```

The Windows build was `10.0.19044.1288`, so it did not have the 1706 update, but it was newer than what I have specified in the MinVersion: 19044 > 19041, so it let the user install the app, even though the OS **did not meet the requirements**.

### Steps to reproduce the bug

1. Have a Windows installation that does not include the 1706 (for Windows 10), or 675 (for Windows 11) KB
2. Try to open any app that requires elevation to run
3. The behaviour would be problematic in some of the cases so I'll illustrate a table below:

___

| Case | Specified min version | Current OS version | What happens | Test | Observations |
| ----- | ------------------------ | ---------------------| ---------------- | ------ | --------------- |
| 1 | 10.0.19041.1706 | 10.0.19044.1288 | installation allowed | $\color{Red}{\text{fail}}$ | 19044 > 19041 |
| 2 | 10.0.19041.1706 | 10.0.19041.1288 | installation blocked | $\color{Green}{\text{pass}}$ | 19041 = 19041 |
| 3 | 10.0.19041.1706 | 10.0.22000.0 | installation allowed | $\color{Red}{\text{fail}}$ | 22000 > 19041 |
| 4 | 10.0.19044.1706 | 10.0.19041.0 | installation blocked | $\color{Green}{\text{pass}}$ | 19041 < 19044 |

___

Works only when the major version is bigger than or equal to the current OS major version, but there are no checks for 1709 or 635 being actually installed.

### Expected behavior

The app should not be allowed to be installed on systems that have these updates missing, which Windows App SDK relies on to have support for elevation. I would expect to see the same error when I try to install the application: that the system does not meet the requirements. This should work when:
- installing the app from the Store
- installing the app from winget
- installing the app via powershell with `Add-AppxPackage` command
- installing the app using the `AppInstaller`

There are cases where the app **is based on elevation**, and doesn't have just one or two features that could be hidden if these update are not installed. For these apps, that don't get to runtime, there's no feature support that would let the developer to specify the needed dependencies.

### Screenshots

_No response_

### NuGet package version

None

### Packaging type

Packaged (MSIX)

### Windows version

10, 11

### IDE

_No response_

### Additional context

Since my app targets advanced users who want control over their OS, this case is pretty common. People don't tend to update to the latest version of Windows 11 as they love Windows 10, they might turn off updates, or just stick with what they have because of commodity. Other scenarios are when people download LTSC ISOs from Microsoft, which do not include these updates by default so they have no clue about the fact that the app requires such thing.

There is a workaround in which I override the XAML generated main method and do the runtime check there, but this is very limited and not great for the UX. **Since the app is allowed to be installed, the user expects it to work**.

``` C#
public class Program
{
[STAThread]
static int Main(string[] args)
{
// code to check for the missing update

WinRT.ComWrappersSupport.InitializeComWrappers();

Application.Start((p) =>
{
var context = new DispatcherQueueSynchronizationContext(DispatcherQueue.GetForCurrentThread());
SynchronizationContext.SetSynchronizationContext(context);
_ = new App();
});

return 0;
}
}
```

This approach gives me a few options:
- show a native dialog box that the app won't work
- show a toast notification informing the user about the missing dependencies
- logging a more explicit error in the EventViewer

None of these options are optimal or a best practice in terms of UX, and are annoying for the user, ruining the first impression of the application, this being a success factor.

No repository files or tests are named. Start by tracing how TargetDeviceFamily MinVersion and package dependency checks are handled for elevation support, then compare installation through the Store, winget, Add-AppxPackage, and AppInstaller. Done means apps requiring elevation are blocked when the required Windows servicing KB is absent, with the expected unmet-requirements error.

Written by the indexing model from the issue text.