Surface `winapp run --debug-output` / `--symbols` for crash triage

Background

winappcli 0.6.1 has two winapp run options the extension never surfaces:

• --debug-output — winapp attaches itself as the debugger. Streams OutputDebugString and first-chance exceptions inline, filtering framework noise (WinUI, COM, DirectX internal traces) from the console while writing everything to a log file. On crash it captures a minidump and analyzes it automatically: managed (.NET) crashes yield exception type, message, and a stack with source file and line numbers resolved from PDBs in the build output; native (C++/WinRT) crashes yield module names and offsets. For WinUI it additionally runs automatic stowed-exception triage, decoding the 0xC000027B exception and the native Microsoft.UI.Xaml → CXcpDispatcher → CoreMessagingXP → CLR host dispatch chain that ordinary stacks lose.
• --symbols — downloads PDBs from the Microsoft public symbol server for real native function names, plus the OS symbols (combase.dll) the stowed-exception decode needs. Only meaningful with --debug-output.

See winappcli docs/debugging.md ("Scenario E").

Why this needs its own design decision

This is an alternative workflow, not an option on the existing one:

• Windows permits one debugger per process, so winapp's diagnostics and VS Code's breakpoints are mutually exclusive by construction.
• The CLI forbids --debug-output with --json, which WinAppDebugAdapterFactory depends on to parse the launched PID.

So it cannot be bolted onto the existing launch-and-attach path. It answers "why did my app crash?", whereas the current adapter answers "let me step through my code" — and the WinUI triage specifically targets the case where breakpoints are useless because the stack has already unwound.

Options to decide between

• (A) Advanced palette command only — expose the toggles in a winapp run options prompt; reject them in resolveDebugConfiguration with a pointer to that command. Simplest, no adapter changes, but leaves WinUI crash triage behind a palette flow users won't find when their app just crashed under F5.
• (B) A non-attach "diagnostics" debug mode — e.g. "attach": false / "mode": "diagnostics" on the winapp debug type. The adapter skips --json/PID parsing and the child debug session entirely, streams stdout to the WinApp output channel, and ends the session when the process exits. Gives WinUI developers a "crash-triage F5". Costs a real adapter branch and a second set of docs.

Prerequisite

Tracked as a follow-up to the winapp run project-mode work. That work introduces src/run-options.ts with WinAppRunOptions (already including debugOutput/symbols fields) and validateRunOptions (already encoding the --debug-output + --json and --debug-output + --no-launch conflicts), so this issue should be a UI-surface change only.

Start with src/run-options.ts and validateRunOptions to understand the existing debugOutput and symbols fields and their conflicts. Then inspect resolveDebugConfiguration and WinAppDebugAdapterFactory while comparing the two proposed workflows. Done means one workflow is chosen and its UI surface, validation behavior, and documentation are consistent with that decision.