Winget as SYSTEM fails to upgrade certain packages

Brief description of your issue

As the title states, I've noticed that when my script - that fires off Winget Upgrade as NT AUTHORITY\SYSTEM- is run, the log that it creates doesn't show this issue yet it does exist. So when thru my script I run the winget client in the SYSTEM context, it fails to recognize app packages it could upgrade, and that which it would upgrade if I were to run it in the USER context.

Does this make sense? I'm running the winget client as SYSTEM as a scheduled task thru the powershell script I wrote, the logs don't show any issues whatsoever, and of course, this scheduled task returns 0x0 so it does run and complete successfully every single time it's run - once daily. And it does find and upgrade some packages - in the SYSTEM context - but not all, and this is my problem.

The reason why I'm running it in the SYSTEM context is because I don't want to fire off any UAC prompts, any pop-ups, any prompts whatsoever for the end-user; I want it to work as a scheduled task completely silently in the background without the end-user ever noticing it in the first place.

Can I please get some input on this?

Steps to reproduce

I wrote a script that ran winget as NT AUTHORITY SYSTEM

I wrote another one that ran winget as USER

Expected behavior

NT AUTHORITY SYSTEM should discover ALL packages that can be upgraded.

Actual behavior

NT AUTHORITY SYSTEM fails to even discover some packages that can be upgraded

Environment

Windows Package Manager v1.7.10861
Windows: Windows.Desktop v10.0.22631.3296
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.22.10861.0

No source files, tests, or entry points are named. Reproduce the comparison between winget upgrade under NT AUTHORITY\SYSTEM and USER using the provided Windows and WinGet versions, then inspect the resulting logs and package-discovery behavior. Done means SYSTEM discovers the same upgradeable packages as USER without prompts.