/cso on Windows: setup fails with "Staged CSO core is not one executable regular file" — staged core, launcher and generation vanish before the publish step #3071

Environment

• gstack 1.91.33.0 (commit db74567), installed at ~/.claude/skills/gstack
• Windows 11 Pro 10.0.26300
• Git for Windows (Git Bash), Bun 1.4.2
• Visual Studio Build Tools 2022 17.14.41 with "Desktop development with C++"
• PowerShell 7.6.6

Summary

./setup --refresh-registered fails in the CSO publish step. MSVC compiles both
launcher-windows.c and publish-lock.c successfully, and every pre-publish check
in scripts/build-cso.sh passes. But when the child Bash started by
gstack-cso-publish-lock.exe runs cso_publish_locked, three files are no longer
in the stage directory, so it fails with:

Staged CSO core is not one executable regular file.

Evidence

1. Parent run (bash -x scripts/build-cso.sh): cso_valid_artifact passes for
   gstack-cso-core.exe, gstack-cso-launcher.exe and gstack-cso-publish-lock.exe;
   cso_valid_generation passes; the core SHA-256 matches the generation file;
   gstack-cso-launcher.exe --version succeeds; then:

   exec .../bin/.gstack-cso-stage.XXXX/gstack-cso-publish-lock.exe .../bin 'C:\Program Files\Git\usr\bin\bash.exe' .../scripts/build-cso.sh __publish_locked .../bin/.gstack-cso-stage.XXXX

2. Child run (xtrace via exported SHELLOPTS): cd into the stage works and the
   case prefix check passes, but [ -f .../gstack-cso-core.exe ] is false.

3. Listing the stage at the moment of the error (via an exported echo override
   that runs ls -la and PowerShell Get-ChildItem on $CSO_STAGE; both agree):

   .gstack-cso-generation.lock 0 bytes
   gstack-cso-publish-lock.exe 144384 bytes
   previous/ (directory)

   Missing: gstack-cso-core.exe, gstack-cso-launcher.exe, .gstack-cso-generation.
   The file that survives is the one that is executing (publish-lock.exe).

4. Not the cause, as far as we can tell:

   • No Windows Defender detections in the period.
   • No delete/move calls in launcher-windows.c or publish-lock.c.
   • A plain bash -c 'trap ... EXIT; exec <native exe>' does not run the EXIT trap
     on this machine.
     The component that removes the three files is unknown.

Secondary issue: hard-coded Windows PowerShell 5.1

setup (toolchain probe) and scripts/build-cso.sh call powershell.exe by name.
On this machine Windows PowerShell 5.1 crashes with 0xC0000005
(exit -1073741819, faulting module unknown, offset 0x0), so setup reported:

CSO unavailable: its native helper was not built (windows-msvc-toolchain)

That message is misleading: any probe failure that is not a compile error is
labeled "windows-msvc-toolchain", even when Build Tools are installed. Running the
same probe with pwsh returns 0. Workaround used to get past the probe:

powershell.exe() { pwsh "$@"; }; export -f powershell.exe; ./setup --refresh-registered

Suggestions: prefer pwsh when available (or allow an override), and report the
real probe output instead of "windows-msvc-toolchain".

Steps to reproduce

1. Windows 11, Git Bash, VS Build Tools 2022 with C++, Bun 1.4.2, gstack 1.91.33.0.
2. Get past the PowerShell 5.1 probe (workaround above, or on a machine where 5.1 works).
3. cd ~/.claude/skills/gstack && bash scripts/build-cso.sh
4. Result: "Staged CSO core is not one executable regular file." Previous install left in place.