1.6.x: HardwareIdentification.GetPackageSpecificToken(...) throws COMException now

Describe the bug

Using any 1.5.x or older version, Windows.System.Profile.HardwareIdentification.GetPackageSpecificToken(...) yielded a result (maybe the COMException was encountered once or twice based on which thread it has been invoked within, but then it was working quite fine) even for packaged WinUi3 applications running with fulltrust.

However, sadly, after trying to upgrade to any 1.6.x WindowsAppSdk, the COMException will inevitably be thrown!

Using an AppContainer is also not an option, since there are still many open issue available with file access not working, not even upon using pickers.
Also figuring out a different approach as to be receiving an unique app- and hardware-specific identifier won't be an option here, since this approach has been in place even back then when the app was built for Windows 8.1 which then was migrated to UWP and later on to WinUi3.
Some aspects of the received app specific hardware identifier are used as an identification within our licensing process, whereas changing that approach now would result in each and every device consuming another seat (unless someone identifies the outdated seats and renews their licenses (but since the licensing process is shared for several solutions (e.g. Android & iOS as well), that might not be easily feasible either or at least very cumbersome if different 'client types' are used)).

Steps to reproduce the bug

1. Setup test application using 1.5.x
2. ensure the app is packaged and running in fulltrust
3. invoke "HardwareIdentification.GetPackageSpecificToken(null)" several times (different threads and at different times)
4. please note that the COMException will not be thrown (unless it is still invoked while app setup process settles)
5. update using SDK 1.6.x now
6. please note that each and every "HardwareIdentification.GetPackageSpecificToken(null)" call is now destined to fail

Expected behavior

Like for 1.5.x, the "HardwareIdentification.GetPackageSpecificToken(...)" should not yield a COMException.

Especially since the documentation of the "HardwareIdentification.GetPackageSpecificToken(...)" method still states that one of its primary purposes is to be used for licensing:

Screenshots

As shown below, the call succeeded using SDK 1.5.x and below (even for packaged fulltrust applications):

NuGet package version

Windows App SDK 1.6.1: 1.6.240923002

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 22H2 (22621, 2022 Update)

IDE

Visual Studio 2022

Additional context

No response

No source file or test is identified. Start by reproducing HardwareIdentification.GetPackageSpecificToken(null) in a packaged fulltrust app on Windows 11, comparing Windows App SDK 1.5.x with 1.6.x; done would mean the call no longer throws COMException on 1.6.x.