Windows: bun link shim is unrunnable when bun came from npm — gbrain.exe can't find bun.exe on %PATH% #2487

Summary

On Windows, gstack-gbrain-install runs bun link and reports success, but the resulting
gbrain is unusable if bun was installed via npm rather than the official bun.sh installer.
The generated gbrain.exe shim resolves bun through %PATH% and looks specifically for
bun.exe, which an npm install never puts there.

Related but distinct from #1271 (that one is bun's [eval] failing to parse shell redirects in
gbrain's postinstall). This is about the linked shim being unrunnable after a successful link.

Environment

• OS: Windows 11 Enterprise 10.0.26200, MINGW64 (Git Bash via Claude Code's Bash tool)
• gstack: v1.61.0.0
• gbrain: 0.42.74.0 (latest HEAD)
• bun: 1.3.14, installed via npm i -g bun
• Path picked: 3 (PGLite local)

What happens

gstack-gbrain-install completes the clone, bun install --ignore-scripts, and bun link:

gstack-gbrain-install: running bun install --ignore-scripts in /c/Users/<you>/gbrain (Windows shell detected)
gstack-gbrain-install: running bun link in /c/Users/<you>/gbrain

bun link genuinely succeeds — ~/.bun/bin/gbrain.exe and ~/.bun/bin/gbrain.bunx both exist.
But running the shim fails:

$ ~/.bun/bin/gbrain.exe --version
error: bun is not installed in %PATH%

Please run the following command, or double check %PATH% is right.

    powershell -c "irm bun.sh/install.ps1|iex"

The remediation it suggests is wrong for this case: bun is installed, and re-running the
bun.sh installer is a second parallel bun rather than a fix.

Root cause

An npm-installed bun lays out:

%APPDATA%\npm\bun            <- POSIX shell script (works in MSYS bash only)
%APPDATA%\npm\bun.cmd
%APPDATA%\npm\bun.ps1
%APPDATA%\npm\node_modules\bun\bin\bun.exe   <- the actual Windows executable

%APPDATA%\npm is on %PATH%, so bun resolves fine in bash and PowerShell. But
node_modules\bun\bin is not on %PATH%, so there is no bun.exe anywhere on it. The
gbrain.exe shim that bun link generates does a Windows-native lookup for bun.exe, finds
nothing, and bails.

Confirmed by putting only that directory on PATH and changing nothing else:

$ export PATH="/c/Users/<you>/AppData/Roaming/npm/node_modules/bun/bin:$PATH"
$ ~/.bun/bin/gbrain.exe --version
gbrain 0.42.74.0

Second, smaller half of the same problem: ~/.bun/bin is itself not added to %PATH% in this
configuration (the bun.sh installer is what normally does that), so even a working shim is not
callable as gbrain. The installer's own D19 check reports this correctly —
bun link completed but 'gbrain' is not on PATH — but on this machine it never got that far,
because the jq-based version read at bin/gstack-gbrain-install:174 aborts first (that part
is #1675 item 2, still open).

Impact

/setup-gbrain cannot complete on Windows + npm-installed bun without manually discovering the
node_modules\bun\bin path. Nothing in the error output points at it, and the one hint that is
printed actively misleads. Every downstream step is blocked, since they all shell out to gbrain.

Suggested fix

In gstack-gbrain-install, after bun link on Windows, validate that bun.exe is resolvable
Windows-natively (not just that bun resolves in the MSYS shell) and, on failure, print
remediation that names this case:

gbrain.exe resolves `bun` through %PATH% and needs bun.exe specifically.
Your bun came from npm, which only installs bun.cmd/bun.ps1 there.
Add this to PATH:  %APPDATA%\npm\node_modules\bun\bin

Deriving the directory from dirname $(command -v bun)/node_modules/bun/bin covers the npm
layout without hardcoding. A more robust alternative is to stop depending on the linked shim
on Windows and invoke bun <install-dir>/<entry> by absolute path, which also sidesteps
~/.bun/bin not being on PATH.

Workaround for anyone hitting this now

Append both directories to the user PATH, then re-run /setup-gbrain:

%APPDATA%\npm\node_modules\bun\bin
%USERPROFILE%\.bun\bin

Setup then completes end to end. For the record, the rest of the run was clean once past this:
PGLite + a local ollama:nomic-embed-text provider indexed 1,559 pages / 16,186 chunks, and the
MCP registration reported ✔ Connected.