WinDbg installer: redundant intermediate disk extraction and no feedback during temp cleanup

Summary

The WinDbg/TTD installer used a hand-rolled ZIP/inflate parser and materialized a large intermediate file to disk, so the install appeared to hang on the "Verifying installation..." step.

Background

For a current WinDbg package the installer touched roughly 1.9 GB of temporary disk I/O. The inner windbg_win-x64.msix (381 MB) was written to a temp file only to be reopened and read straight back, then deleted.

Symptom: "Verifying installation..." appears stuck

CheckInstallation() itself is instant (six fs::exists checks). The perceived hang was the CleanupTempFiles() call that ran right after it. Measured: deleting the freshly-written 381 MB inner .msix took ~68 s — not because the raw delete is slow (that's ~85 ms) but because antivirus scans the just-written archive synchronously on delete.

Resolution (landed in #1128)

• Replaced the homegrown ZIP/inflate parser (vendor/minizip-ng, ~45 KB of bespoke code — despite the name, not upstream minizip-ng) with the vendored, well-audited miniz amalgamation. Also removes a bespoke parser from a supply-chain-sensitive path and fixes the old reader's 2 GB (long) offset limit.
• Extract the inner package directly from memory (mz_zip_reader_init_mem) into the install dir — no intermediate .msix file is written or later deleted.
• Gave the cleanup step its own progress message.

Measured (real 1.13 GB package): whole install ~87 s → ~17 s; cleanup ~68 s → 0 ms (nothing to delete). The remaining ~17 s is the actual writing of 1446 payload files.

Follow-up (not in #1128)

In the real download path the 1.13 GB .msixbundle itself is still deleted at the end and could hit the same antivirus scan-on-delete cost. Worth measuring separately; the inner-package temp (the ~68 s case) is resolved.

The main issue says the fix landed in #1128, including direct in-memory extraction and progress feedback. Read that change first, then measure deletion of the outer .msixbundle in the real download path; done means determining whether antivirus scanning still causes a significant delay and documenting the result or follow-up scope.