fix(windows): release FFmpeg memory and capture native crashes

ui/flutter/windows/runner/CRASH_DIAGNOSTICS.md

@@ -0,0 +1,31 @@
+# Windows native crash diagnostics
+
+The runner installs diagnostics before starting Flutter and plugins. Files are
+written beside the executable under `storage/logs`, matching Windows app storage:
+
+- `native-crash.log`: UTC timestamp, app version, process/thread, exception code,
+  faulting module/address/offset, and minidump success or the Windows error code.
+- `native-crash.dmp`: the most recent native crash, including thread stacks,
+  loaded modules and unloaded module information.
+- `crash.log`: Go runtime crash output, kept separately from native diagnostics.
+
+Logs are appended and existing dumps survive normal restarts. A subsequent native
+crash replaces the previous dump. Dump generation is best effort, particularly
+for stack exhaustion, heap corruption or unavailable disk space. Process kills
+and fail-fast termination can bypass exception handlers.
+
+The top-level unhandled filter covers native exceptions on process threads. An
+SEH boundary inside the runner's window callback records the original escaping exception
+before Windows wraps a window callback failure as `0xC000041D`. A vectored handler
+also observes that fatal callback status, since it can bypass the unhandled
+filter. All handlers continue exception processing; they do not attempt recovery
+or log ordinary handled first-chance exceptions.
+
+On Windows, verify a release build by exercising tray clicks, Explorer restart,
+system font changes and child-window open/close. In a disposable test build,
+raise an unhandled access violation inside a window callback and on a worker
+thread, then raise `0xC000041D`; check that the log and dump are written and
+survive relaunch. A debugger may intercept these before application handlers.
+Open the dump with WinDbg and matching runner/Flutter/plugin PDBs to locate the
+faulting stack. Minidumps can contain application data; inspect them before
+sharing.