Breakpoint experience unhelpful in WinUI Apps

Nobody has claimed this yet.

### Describe the bug

When you write code that causes an exception to occur, very often the exception will be shown in App.xaml's UnhandledException handler, instead of where the exception occurred. This significantly slows down the inner developer loop, because extra time is spent trying to figure out where the exception occurred. It can also easily be (mis)interpreted as a bug with the Windows App SDK and not user code, giving a worse impression of the SDK overall.

This is part of these death-by-1000-razor cut issues that makes the developer experience really poor.

### Steps to reproduce the bug

1. Create a new WinUI project.
2. in MainWindow.xaml.cs add the following code:
```cs
public MainWindow()
{
InitializeComponent();
this.Activated += MainWindow_Activated;
}

private void MainWindow_Activated(object sender, WindowActivatedEventArgs args)
{
throw new ArgumentException(); // Imagine you do something here that occasionally causes an exception
}
```
3. Run the application and observe the exception experience:

### Expected behavior

This is the experience I would have preferred, which helps me faster realize the issue and allow me to move on:
That will also give me access to the state in the thread right here and inspect what went wrong.

As a workaround this can be achieved by realizing this is an ArgumentException and turning on first-chance exceptions, but it requires being able to reproduce the issue right then and there with that first-chance break set on, but from the developer's point of view this isn't a first chance, since there is no try-catch.

Also if you repeat this example in WPF, you'll get the correct breakpoint, .

### Screenshots

_No response_

### NuGet package version

Windows App SDK 1.8 Experimental 2: 1.8.250515001-experimental2

### Packaging type

Packaged (MSIX)

### Windows version

Windows 11 version 24H2 (22621, October 2024 Update)

### IDE

Visual Studio 2022

### Additional context

_No response_

Start by reproducing the exception in MainWindow.xaml.cs using the provided WinUI project steps, then inspect how App.xaml's UnhandledException handler affects Visual Studio break behavior. Compare the result with WPF and verify that an exception from the Activated handler breaks at its throw site with thread state available.

Written by the indexing model from the issue text.