win-dumpconfigurator: Confusing kdbgctrl.exe debug output shown to users

[sdolgin]

The win-dumpconfigurator.ps1 script passes raw kdbgctrl.exe output directly through Log-Output without filtering, resulting in confusing internal debug messages being displayed to users. Other scripts in this repo (e.g., win-toggle-safe-mode.ps1, win-sfc-sf-corruption.ps1) parse and filter external tool output before logging. This script should follow the same pattern.

Current output

[Output] User Requested dump type is full  Dump type from system registry is Invalid  
Change the dump type on the System  lastError after QueryDosDevice call is 3 
Result of core dump Handle to increase pagefile is success  Successfully updated dump settings

Confusing messages:

• Dump type from system registry is Invalid — Appears to be an error, but is actually expected. The script intentionally sets CrashDumpEnabled=0 before calling kdbgctrl, so kdbgctrl reads "0" and reports it as "Invalid".
• lastError after QueryDosDevice call is 3 — Internal Win32 debug trace (ERROR_PATH_NOT_FOUND) that kdbgctrl logs after a QueryDosDevice call. Not user-actionable and does not indicate failure.

Expected output

[Output] Current dump configuration: Automatic (7)
[Output] Requested dump type: full (Complete Memory Dump (CrashDumpEnabled=1))
[Output] DumpFile path set to: %SystemRoot%\Memory.dmp
[Output] Successfully updated dump settings to 'full' via kdbgctrl.
[Output] Verified dump configuration:
[Output]   CrashDumpEnabled : Complete/Full (1)
[Output]   DumpFile         : C:\Windows\Memory.dmp

Proposed fix

1. Parse kdbgctrl.exe output for success/failure instead of raw passthrough
2. Log before/after configuration with human-readable dump type names
3. Verify final configuration by reading back the registry
4. Use Log-Error for actual failures, Log-Warning/Log-Debug for unexpected output