WinUI 3: Async confirmation in AppWindow.Closing causes crash (0xc0000005) due to missing deferral support

### Describe the bug

When handling `AppWindow.Closing` in WinUI 3, if the close is cancelled (`args.Cancel = true`), an async UI operation is awaited (e.g., `ContentDialog.ShowAsync`), and `Close()` is called afterwards, the app often crashes with:

The program '[xxxx] MyApp.exe' has exited with code 3221225477 (0xc0000005) 'Access violation'.

This appears to be caused by the lack of async deferral support in `AppWindow.Closing`. By the time the awaited operation completes, the underlying native window may already be partially destroyed, and calling `Close()` dereferences freed memory.

### Why is this important?

This affects any app that needs to confirm close with async UI (e.g., `ContentDialog`) when the user clicks the window close button.
It forces developers to choose between:
- Blocking the UI thread with synchronous dialogs (bad UX)
- Risking native crashes

### Steps to reproduce the bug

1. Run the attached minimal WinUI 3 project.
2. Click the window's close button.
3. When the confirmation dialog appears, click **Yes**.
4. Observe crash with `0xc0000005`.

### Actual behavior

The app crashes with `0xc0000005` when `Close()` is called after an awaited async operation in `AppWindow.Closing`.

### Expected behavior

It should be possible to:
- Cancel a close request
- Await an async confirmation dialog
- Call `Close()` later

without causing a native access violation.

### Screenshots

_No response_

### NuGet package version

1.8.260317003

### Windows version

Windows 11 (24H2): Build 26100

### Additional context

**Environment**
- Windows App SDK: [1.8.260317003]
- WinUI 3: Desktop, Packaged
- OS: [Windows 11 Pro 25H2 26200.8117]
- Architecture: x64 / ARM64
- Build Config: Debug / Release (both crash)

**Analysis**
- `AppWindow.Closing` has no `GetDeferral()` method like UWP’s `CoreWindow.Closing`.
- Async operations in this event handler allow the native window to enter a partially destroyed state.
- Calling `Close()` after this point dereferences freed native resources → access violation.

**Suggested Fix**
- Add async deferral support to `AppWindow.Closing` so that the close operation can be safely delayed until async work completes.
- Alternatively, document that async work in `Closing` is unsafe and provide a supported pattern for async confirmation.

**Attachments**
- [ZIP] Minimal repro project

[CrashRepro.zip](https://github.com/user-attachments/files/26418125/CrashRepro.zip)

Start by running the attached CrashRepro.zip and reproducing the failure from the AppWindow.Closing handler after the async confirmation completes. Read the AppWindow.Closing behavior and its cancellation flow; done means establishing a supported async-confirmation pattern that avoids the access violation, or documenting the safe alternative if deferral support is not feasible.

Written by the indexing model from the issue text.