Additional details should be contained when using a pipeline with commands like Update-WinGetPackage

Brief description of your issue

Attempting to update selected packages using Get-WinGetPackage | Where IsUpdateAvailable -eq $True | Out-GridView -PassThru | Upgrade-WinGetPackage

On certain packages, and only sometimes, will an error message like this be returned
Update-WinGetPackage: No packages matched the given input criteria.

Diagnosing this, is made harder than it should be and where possible we should pass the data passed via the pipeline in the output Error Record, with the recommendation to add it in the TargetObject property. This would then make it so that we can diagnose these issues easier & potentially add problematic packages to a DNI/U (Do not install/update) list organisation wide for either a short or long term as to allow users to get on with other more pressing bits of work.

Steps to reproduce

Install Gyan.FFmpeg 7.0.2
Run Get-WinGetPackage | Where IsUpdateAvailable -eq $True | Out-GridView -PassThru | Upgrade-WinGetPackage
Select Gyan.FFmpeg when the GridView pops up to initiate the upgrade of that package

It should fail providing the above message

Expected behavior

Package should install, however if it fails, like this, then we should be able to query the error record for the package that failed.

Note If you ran Update-WinGetPackage -Id Gyan.FFmpeg -Version 7.1 instead you'd capture this in the error record.

Actual behavior

We get no details on which package has been passed to Upgrade-WinGetPackage and just get a generic error.

Environment

Microsoft.WinGet.Client 1.9.25180
PowerShell 7.5.0-rc1

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

Windows: Windows.Desktop v10.0.27768.1000
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.24.25200.0

Winget Directories                 
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett
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
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

Start with the Upgrade-WinGetPackage pipeline path shown in the reproduction and inspect how the generic "No packages matched" error record is created. Done means a failed piped update exposes the package in the error record's TargetObject, while direct -Id usage continues to provide its package details.