PackageManager test apps: retry OpenEventW briefly before giving up

[Vineeth Thomas Alex (vineeththomasalex)]

What

Adds a bounded retry (5s budget, 50ms poll interval) around OpenEventW in the two PackageManager
test apps (PackageManager.Test.M.Black.msix, PackageManager.Test.M.Blacker.msix) before falling
back to the existing failure behavior (RETURN_LAST_ERROR_IF_NULL, immediate exit).

Why

Follow-up to the investigation into the residual PackageDeploymentManagerTests_IsPackageRegistrationPending
failures (IsPackageRegistrationPending_Pending / IsPackageRegistrationPendingForUser_Pending),
which fail deterministically on every CI config where InteractiveExperiences is built from source
in the monobuild (they pass on stub IXP builds).

Exhaustive local investigation ruled out every code-level and timing-level hypothesis:

• The raw PackageManagement_IsPackageRegistrationPending FrameworkUdk export — correct in both
  stub and source-built DLL variants (direct P/Invoke, single-call and same-process-ordering tests).
• The compiled Microsoft.WindowsAppRuntime.dll WinRT wrapper — correct (direct
  DllGetActivationFactory harness, both DLL variants).
• A timing race between ActivateApplication and the deferred install — correct with zero
  artificial delay, tested via both PowerShell and a fully-native C++ harness replicating the real
  test's exact call sequence.
• PackageDeploymentManagerTests_Register's ClassSetup cascade polluting this class — ruled out:
  the failure occurs on Windows.10.Enterprise.LTSC.2021 (a config with zero _Register
  cascade failures), and _IsPackageRegistrationPending's tests run and complete before any
  _Register test starts.
• The real, completely unmodified TAEF test itself — built the actual PackageManagerTests.dll
  • its full dependency chain (Framework/DataStore/LifetimeManager/Singleton MSIX packages) from
    source and ran it via real te.exe on an IXPTools VM. Passed 4/4 consecutive runs, zero
    modifications to any test file.

The one concrete fragility found: this app's WinMain parses its activation argument as an event
name and calls OpenEventW exactly once. If that ever transiently fails to see the caller's
CreateEventW-created event (e.g. a broker/activation-scheduling timing variance specific to some
CI execution contexts, not reproduced in this investigation's VM), the app exits almost instantly
instead of holding the package "in use" — producing exactly the observed symptom: no exception, no
error, IsPackageRegistrationPending() correctly (from the OS's perspective) reports nothing
pending because the deferred upgrade already silently completed.

Honest scope of this change

This is defensive hardening for an identified robustness gap, not a proven fix for a fully
confirmed root cause. The CI-specific trigger mechanism could not be force-reproduced locally
despite exhausting every constructible hypothesis. If a CI run with this change still fails the
same way, that's meaningful evidence the real cause lies elsewhere (e.g. a CloudTest-infrastructure
scheduling/session issue outside this app's control) — this change should still stand on its own
merits as a legitimate improvement to test-app robustness.

Test-infrastructure only

Only the two MSIX test app winmain.cpp files change (identical diff in both, 15 lines added each).
No product code changes.

Local verification

• Rebuilt both hardened MSIX packages — compiles cleanly.
• Ran the full PackageDeploymentManagerTests_IsPackageRegistrationPending class (8 methods,
  including both _Pending variants) via real te.exe against the real, unmodified test binary and
  real MSIX/Framework/Bootstrap infrastructure on an IXPTools VM: 8/8 Passed, 0 Failed, no
  regression from the added retry loop in the already-passing case.

Separate from #6693 (the cascading ERROR_PACKAGES_IN_USE fix, out of scope here per that PR's own
"no need to fix it in this PR" guidance for these residual tests).

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.