fix(tests): resolve Git Bash explicitly so WSL cannot claim bash

[ppcvote]

Fixes #206.

The release-automation suite spawns an unqualified bash in 20 places. On Windows that resolves against PATH, and with WSL enabled C:\Windows\System32\bash.exe is a real executable that frequently precedes Git for Windows. The extracted workflow fragments then run inside WSL, where the Windows node, gh and jq this suite depends on are absent and its Windows path assumptions do not hold.

Measurement

I could not reproduce this by accident: on this host where.exe bash happens to return Git Bash first, so the suite was already green. I reproduced it deliberately by putting System32 ahead of Git on PATH, which is the reporter's configuration.

Windows 10, Git for Windows 2.52.0, WSL2 enabled, bun 1.3.11:

PATH order	before	after
System32 first (as reported)	116 pass, 69 fail	180 pass, 5 fail
Git Bash first (this host's default)	180 pass, 5 fail	180 pass, 5 fail

64 tests recovered, and the WSL-first environment now produces exactly what the Git-Bash-first environment does.

The 5 remaining failures are jq: command not found on this host. They are identical before and after and in both PATH orders, so they are an unrelated environment gap on my machine rather than residue from this change.

The change

resolveBash() walks PATH and skips the launcher locations before taking the first bash.exe it finds:

• %SystemRoot%\System32 and %SystemRoot%\Sysnative — the WSL launcher
• any WindowsApps directory — the Store execution alias, also WSL

Non-Windows platforms keep the bare bash they use today, so nothing changes on CI's Linux runners.

Two details worth flagging for review:

• PATH is split on delimiter from node:path rather than a literal ";". I checked what bun actually reports on Windows when launched from Git Bash, and it is a Windows-style semicolon PATH, but splitting on the platform separator is the honest expression of the intent.
• Skipping known launcher locations rather than positively identifying Git Bash is deliberate. Git for Windows ships bash.exe in both Git\bin and Git\usr\bin, and only the first sits next to git.exe, so a positive test would have to encode more layout assumptions than an exclusion does.

Happy to switch to a positive Git-Bash lookup, or to hoist the helper somewhere shared, if either fits the codebase better.