Wrapping COMException which winget can handle

Brief description of your issue

The winget client uses the underlying COMException in case of failures and propagates as is while giving the detail in the status property.

It would be handled better if it was handled not by the status property but as a separate Exception type. In this example, NoApplicableInstallersException.

Now, the said cmdlet does not throw an error even though there is an exception thrown. The current design is against PowerShell guidelines.
The error should be thrown using ThrowTerminatingError according to the Error Reporting Concepts document.

It is a well known situation that teams are isolated within Microsoft, but not following internal guidelines for official MS products is not a proper way of engineering.

Steps to reproduce

Update-WinGetPackage -Name "Burp Suite Community Edition" -Verbose | Format-List
VERBOSE: Performing the operation "Update-WinGetPackage" on target "Burp Suite Community Edition [PortSwigger.BurpSuite.Community] Version 2023.10.2.3".

CorrelationData :
InstallerErrorCode : 0
ExtendedErrorCode : System.Runtime.InteropServices.COMException (0x8A150010): 0x8A150010
RebootRequired : False
Status : NoApplicableInstallers

Expected behavior

VERBOSE: Performing the operation "Update-WinGetPackage" on target "Burp Suite Community Edition [PortSwigger.BurpSuite.Community] Version 2023.10.2.3".
An alternative Exception speciic to Winget

Actual behavior

VERBOSE: Performing the operation "Update-WinGetPackage" on target "Burp Suite Community Edition [PortSwigger.BurpSuite.Community] Version 2023.10.2.3".

CorrelationData :
InstallerErrorCode : 0
ExtendedErrorCode : System.Runtime.InteropServices.COMException (0x8A150010): 0x8A150010
RebootRequired : False
Status : NoApplicableInstallers

Environment

Windows Package Manager v1.6.2771
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.3570
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.2771.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled

Start at the Update-WinGetPackage cmdlet and trace how NoApplicableInstallers is represented through the status property and underlying COMException. Review the ThrowTerminatingError guidance cited in the issue; done means the cmdlet reports a Winget-specific exception instead of only exposing the COMException details.