[Windows] Address AppInstance activation lifecycle review feedback

[IlGalvo]

Summary

Follow-up to #34883 addressing the remaining review feedback without changing the public surface introduced by the parent PR.

• Dispatches later AppInstance.Activated notifications through the MAUI application dispatcher while keeping the initial activation synchronous and able to short-circuit window creation.
• Restores the four missing Core Windows Public API baseline entries.
• Removes the now-redundant window-level dispatch from the Controls Sample.
• Hardens the Windows lifecycle order test against missing-event false positives.
• Limits the new lifecycle device-test coverage to Windows.
• Clarifies the Windows WebAuthenticator callback-routing contract and moves its Windows-only tests into the existing Tests/Windows/ layout.

Threading and lifecycle behavior

MauiWinUIApplication captures the application dispatcher after app-level services are available. Initial activation continues to run synchronously before OnLaunching and window creation, preserving the existing bool handled contract. Only later AppInstance.Activated callbacks are dispatched when required; if dispatch is rejected during shutdown, the callback is not run off-thread.

Test scope

The Android and iOS/MacCatalyst lifecycle tests added by the parent PR are intentionally removed:

• The change is Windows-specific, while those tests cover pre-existing platform lifecycle events.
• The Android headless runner can begin executing tests before OnStart/OnResume delivery completes, creating a startup race.
• The Apple headless runner uses MauiTestApplicationDelegate rather than the normal MauiUIApplicationDelegate lifecycle path.

Those files do not exist on main, so this does not remove established MAUI coverage. Addressing the cross-platform runners belongs in a separate change.

Intentional review decisions

• No exception is added for application-owned AppInstance keys. Single-instance apps preserve their own key and redirect protocol activations to the original instance, where the MAUI lifecycle callback completes WebAuthenticator. Throwing would break that supported pattern.
• System.Threading.Tasks remains in the Controls Sample because it provides the .AsTask() extension used with RedirectActivationToAsync.
• MauiProgramDefaults remains unchanged because Core.DeviceTests.Shared has nullable annotations disabled; its optional delegate follows the existing project convention.

Validation

Automated/local:

• Core Windows build: passed
• Essentials Windows build: passed
• Controls Sample Windows build: passed
• WebUtils_Tests: 20/20 passed
• Core Windows lifecycle device tests: 3/3 passed
• Essentials Windows WebAuthenticator helper device tests: 14/14 passed
• Core and Essentials Windows DeviceTests projects: built successfully

Manual Windows validation:

• A true second Controls Sample instance redirected to the original instance and terminated; the original window handled the activation on the UI thread.
• The real WebAuthenticator browser/callback flow was validated on Windows.

Android, iOS, and MacCatalyst runtime tests were not run for this Windows-only follow-up.

Thanks in advance,
@mattleibow
@kubaflo

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Hey there @@IlGalvo! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[dotnet-policy-service]

Hey there @IlGalvo! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.