fix: Prevent OOM exception cascade in dispatcher handler

[sentry]

The root cause analysis for AUTOMIDIPLAYER-14 identified that a System.OutOfMemoryException originating from WPF's rendering pipeline (Channel.SyncFlush) was being amplified into a storm of 31 identical errors. This occurred because the OnDispatcherUnhandledException handler in Bootstrapper.cs responded to the OOM by attempting to open a new CrashMessageBox window. Under memory pressure, creating this new window would itself trigger another OOM, leading to a re-entry into the handler and a continuous cascade of exceptions.

This fix addresses this by:

1. Adding a re-entrancy guard: A static _handlingDispatcherException flag, managed with Interlocked, prevents the handler from re-entering itself if it's already processing an exception. Subsequent rapid exceptions are swallowed to break the cascade.
2. Special-casing memory exhaustion: The IsMemoryExhaustion helper method detects OutOfMemoryException (and its inner exceptions). If an OOM is detected, the handler avoids creating the WPF-based CrashMessageBox.
3. Implementing a lightweight failure path for OOM: For OOMs, the exception is captured and flushed to Sentry, and then the application is immediately shut down. This prevents further attempts to render UI elements that would likely fail and re-trigger the OOM.
4. Explicitly handling exceptions: e.Handled = true is now explicitly set in all relevant paths to ensure the dispatcher doesn't re-process the exception.

This change ensures that a single memory exhaustion event results in a single, clean Sentry report and a graceful shutdown, rather than an overwhelming flood of errors.

Fixes AUTOMIDIPLAYER-14