Destructive Command Guard

Fixes Windows binary mismatch (#115)

v0.5.1 shipped Linux ELF binaries under the dcg-x86_64-pc-windows-msvc.zip / dcg.exe asset names because the GH Actions test job failed and the dsr fallback path cross-compiled on a Linux host that lacked an MSVC toolchain. The packaging step picked up the host dcg ELF binary because it didn't validate the output format before stuffing it into the Windows-named archive. Windows users hit The specified executable is not a valid application for this OS platform. on every install.

v0.5.2 ships a real PE32+ Windows binary — built locally with x86_64-pc-windows-gnu (MinGW) since the GH Actions queue was backed up (>1 hour) at release time, but named dcg-x86_64-pc-windows-msvc.zip to match install.ps1's expected asset shape. The binary is a genuine PE32+ executable for MS Windows 5.02 (console), x86-64 — file dcg.exe and PowerShell's executable test both confirm it.

Verification gate added (46e76a4)

The release workflow now has a PE32+ verification gate (parallel to the existing GLIBC and aarch64 gates) that checks the first two bytes of the Windows binary are MZ (0x4D 0x5A) before packaging. Any future regression that re-produces ELF-as-EXE fails the release run loud rather than silently publishing bad assets.

Assets

This release ships the linux/darwin/windows matrix matching v0.5.1, plus the new linux/amd64 musl build (matches current main per #114). The x86_64-pc-windows-msvc.zip was cross-compiled via MinGW (x86_64-pc-windows-gnu rustc target) — both toolchains produce PE32+ binaries that work natively on Windows. The naming uses -msvc to match install.ps1's expected asset shape, not to imply MSVC was the link target.

Closes #115.

Full Changelog: https://github.com/Dicklesworthstone/destructive_command_guard/compare/v0.5.1...v0.5.2