fix: Windows Git Bash install fails when unzip is unavailable

[hatayama]

Summary

scripts/install.sh hard-depends on unzip with no fallback, on the exact route the README recommends for Windows Git Bash. Every other external tool the script needs has an alternative; unzip does not.

This is not a malfunction — the script fails fast with a clear message. It is a capability gap that contradicts what the README promises.

The chain (each link verified against the current tree)

1. README.md:120 documents the shell installer for "On macOS or Windows Git Bash".
2. scripts/install.sh:92 always selects the .zip asset on Windows (uloop-dispatcher-windows-amd64.zip).
3. scripts/install.sh:483-487 exits 1 with unzip is required to extract $asset_name when unzip is absent. The tar -xzf fallback lives in a different case arm and is unreachable for .zip.
4. scripts/test-install-release-filter.sh:269 writes a mock unzip onto PATH before exercising the Windows path. The test therefore proves the extraction logic but can never detect that unzip is unavailable on a real Git Bash.

External commands install.sh probes: npm, sha256sum, shasum, uloop, unzip. Note sha256sum/shasum are a deliberate either/or pair — unzip is the only hard single dependency.

Not yet verified

Whether Git for Windows actually ships unzip. This needs a Windows machine and has not been confirmed. The understanding driving this issue is that the Git Bash MSYS2 toolset omits unzip, its bundled tar is GNU tar (no zip support), while the Windows-native System32 tar.exe is bsdtar and does read zip.

If that understanding is wrong, this issue reduces to documenting the prerequisite (option 3 below).

Settling experiment: on a clean Windows box with only Git for Windows installed, in Git Bash check whether unzip resolves, which tar implementation is on PATH, and whether the Windows-native tar.exe exists — then run the installer with a temporary install directory.

Options

1. Add fallbacks — try unzip, then the Windows-native tar.exe -xf, then powershell -Command "[System.IO.Compression.ZipFile]::ExtractToDirectory(...)", erroring only when all three are absent. Harmless whether or not the premise above holds, and matches the existing sha256sum/shasum pattern.
2. Drop the Git Bash claim from the README and route Windows users solely through scripts/install.ps1, which works today.
3. Document the prerequisite — state in the README that the Git Bash route requires unzip.

Option 1 is preferred. It costs a few lines, needs no Windows machine to justify, and removes the question permanently. It also stays consistent with the direction set by #2080 / #2081, which removed the gh and jq dependencies from installation — leaving a hard single dependency on unzip runs against that.

Test coverage

Whichever option is taken, the mock-unzip approach in scripts/test-install-release-filter.sh should be revisited: mocking a tool onto PATH verifies logic but never availability. A case that runs the Windows path with unzip deliberately absent would have caught this.

Provenance

Found by a read-only Windows compatibility audit of the repository (finding F2). No files were modified.

[hatayama]

Fixed in #2400.

squash: cbcdc62