ci: run the bootstrap from pwsh and git bash

[eirikb]

gg.cmd always ends up executing through cmd.exe on Windows, but it inherits the PATH and PSModulePath of whatever shell you started it from. Two bugs shipped through that seam this week:

• crash when using git bash on windows #291 — from Git Bash, C:\Program Files\Git\usr\bin sits ahead of System32, so a bare tar resolved to Git's GNU tar instead of bsdtar. Unpacking died.
• crash on powershell 7 #292 — from PowerShell 7, the child Windows PowerShell inherits pwsh's PSModulePath and loads its Core-only Microsoft.PowerShell.Utility. Binary cmdlets kept working; Get-FileHash vanished.

Neither was caught, and not for the reason I first assumed. The cold path was already tested — has_secret is true on same-repo PRs, so "Pre-populate cache with stage4" is skipped there. The actual gap is the parent shell:

Job	Shell	Invocation	Branch exercised
test-OS1	bash	sh gg.cmd	the shell half — sh is explicit, cmd.exe never sees it
test-batch	cmd	.\gg.cmd	the batch half, but parent is plain cmd.exe

So the batch half was covered and Git Bash was covered, but never Git Bash as parent of the batch half. Both bugs live in that cell.

What this adds

test-parent-shells: one job per parent shell on windows-2022, running .\gg.cmd from pwsh and ./gg.cmd from Git Bash — deliberately not sh gg.cmd, since MSYS dispatching a .cmd to cmd.exe by extension is the whole point.

Each leg runs twice (cold, then the cached branch at stage1.bat:15, which nothing else covered) and asserts what node printed, not just the exit code — stage2.ps1 runs Start-Process -ErrorAction SilentlyContinue and its catch defaults $exitCode = 0, so gg can exit 0 having launched nothing.

The job always runs. When the Azure secret is absent it seeds stage4 from the artifact like the sibling jobs, so fork PRs still cover stage1's unpack — where #291 lives — with only the blob download dropping out. The gatekeeper is strict; no skip exemption.

Verified

Dispatched on real runners: 178 jobs green, 0 failures. Both legs cold-bootstrapped (node not found in cache → download → v26.5.0), then ran warm. The Git Bash leg's own PATH dump confirms the hazard is live there:

PATH: …;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;…;C:\Windows\system32;…

actionlint reports the same findings as main (7 pre-existing shellcheck items) — nothing new.

Honest limits

• The pwsh leg is a real regression test — revert the .NET SHA512 to Get-FileHash and it goes red deterministically. The bash leg is weaker: it proves Git's GNU tar is first on PATH, but with the System32 pin in place GNU tar is never invoked, so reverting the pin might leave it green. It guards the environment more than that specific bug.
• The fork path is unexercised by these runs — a same-repo dispatch has the secret, so the seeding steps skip. Only a real fork PR exercises them.
• The assertions are unproven as detectors — green shows they don't false-positive; it doesn't show they'd catch the swallowed-exit-code case.
• Not done, worth a follow-up: timeout-minutes (the job hits the Azure blob cold every run, and stage2.ps1:92 has no -TimeoutSec or retry), and preconditions asserting the job still reproduces its own premise — Git's tar still shadowing System32, pwsh still ≥ 7.