Almost-blank WinUI 3 project crashes when VS debugger paused on a Page destructor when window is closed while ContentDialog is opened

### Describe the bug

If a ContentDialog is opened in a WinUI 3 application that has its property ExtendsContentIntoTitleBar set to true and then that window is then closed, nothing will happen as expected. However, if those steps are repeated, but a Visual Studio debugger breakpoint is placed on a statement that runs in the destructor of the Page that is in the window, and you let Visual Studio hit the breakpoint, then an error from WinRT will be thrown once execution is resumed.

### Why is this important?

My code creates a low-level keyboard hook in the Win32 API, and I wanted to ensure that this hook is properly cleaned up in the scenario that the application is closed while the hook is still enabled. The hook is only ever enabled at the same time as a specific ContentDialog is open. In other words, there will always be a ContentDialog on screen if this hook is enabled. Since I wanted to test if the hook would be cleaned up properly when the application is closed, I put a breakpoint in some logic in the destructor of one of my classes, whose destructor would just so happen to trigger when my Page's destructor would run.
My code was actually working fine, but I was under the false impression that there was a bug in my code when it was actually a bug in WinUI. I'd imagine that there may be other people who would also at some point want to debug destructor logic by using breakpoints in a destructor, and falsely believe that they have a bug in their code, causing them to end up spending time trying to fix a bug that doesn't exist.

### Steps to reproduce the bug

1. Create a new WinUI 3 Blank Project in Visual Studio.
2. In this blank project, add a new page.
3. Add a Grid in this page's XAML and give it an event handler for the Loaded event.
4. In the XAML code-behind, add some code in the Grid's event handler that creates and shows a ContentDialog.
5. Create a destructor for this page, but don't add anything, just set a breakpoint on it.
6. In MainWindow.xaml, add a Frame, and set its SourcePageType to the page that was just created.
7. In MainWindow's code-behind, set the property "ExtendsContentIntoTitleBar" to true. (It doesn't matter if there is actually anything that is extending into the title bar, this just needs to be set to true.)
8. Press F5 and Start Debugging.
9. Close the app and let the debugger hit the breakpoint that was set on the page's destructor.
10. Continue the code execution.
11. Observe the error generated in Microsoft.UI.Xaml.h.

### Actual behavior

An exception will be thrown that looks something like this:
```
Exception thrown at [...] (KernelBase.dll) in [application]: WinRT originate error - [...] : 'The given object has already been closed / disposed and may no longer be used.'.
Exception thrown at [...] in [application]: Microsoft C++ exception: winrt::hresult_error at memory location [...].
```

### Expected behavior

No exception is thrown.

### Screenshots

_No response_

### NuGet package version

1.8.260224000

### Windows version

_No response_

### Additional context

_No response_

Start with the minimal WinUI 3 reproduction described in MainWindow.xaml, its code-behind, and the added Page XAML/code-behind. Run it under the Visual Studio debugger with a breakpoint in the Page destructor, then inspect the failure reported in Microsoft.UI.Xaml.h after continuing. Done means closing the window with the ContentDialog open no longer throws the disposed-object WinRT error.

Written by the indexing model from the issue text.