fix(windows): .gitignore glob for .exe + find-browse .exe resolution

[Mike-E-Log]

Summary

Two small, narrow Windows-portability fixes that don't appear to be covered by any open PR:

1. .gitignore — match the .exe suffix on bin/gstack-global-discover
2. browse/src/find-browse.ts — resolve the .exe suffix on Windows, mirroring the helper already in make-pdf/src/browseClient.ts:89 and make-pdf/src/pdftotext.ts:52

Verified live on Windows 11 + Git Bash MSYS2 + bun 1.3.13. First-time contributor; please tell me if I've missed a convention.

Scoping note (deliberate omission)

I originally drafted this PR with a third fix for the bun-shell (...) > redirect bug in package.json's build script. On checking the PR list before opening, I found that ground is already heavily covered:

• v1.39.2.0 fix: bun run build crashes on Windows from subshell-with-redirection #1531 (@scarson) — v1.39.2.0 fix: bun run build crashes on Windows from subshell-with-redirection
• Fix Bun Windows build script compatibility #1544 (@Charlie-El) — Fix Bun Windows build script compatibility
• Fix Windows build artifact finalization #1540 (@McGluut) — Fix Windows build artifact finalization
• fix(build): bun-on-Windows compatibility for the package.json build script #1480 (@mikepsinn) — fix(build): bun-on-Windows compatibility for the package.json build script
• v1.33.3.0 fix: replace bash brace groups with subshells in build script for Windows compatibility #1460 (@realcarsonterry) — v1.33.3.0 fix: replace bash brace groups with subshells in build script for Windows compatibility

Five existing PRs is enough — adding a sixth would be noise rather than signal. I dropped that commit before opening this PR. The two fixes here are deliberately the ones that don't overlap with that crowd.

Why each fix exists

Fix 1: .gitignore — bin/gstack-global-discover*

One line:

-bin/gstack-global-discover
+bin/gstack-global-discover*

Why: the pattern was exact-match. On Linux/macOS, bun --compile produces bin/gstack-global-discover (no extension) and the rule matches. On Windows, the output is bin/gstack-global-discover.exe and the rule misses it, so git status shows it as untracked after every build.

Precedent: browse/dist/ (line 4) uses a directory pattern, which catches every extension under the directory. Same conceptual move — make the rule cover both Linux and Windows compile outputs — applies here. The * glob is the minimal change.

Tighter alternatives (happy to switch if preferred): two explicit lines (bin/gstack-global-discover + bin/gstack-global-discover.exe). The glob form would also match hypothetical future siblings like .map or .dSYM; the tracked source bin/gstack-global-discover.ts is unaffected either way (it was added before the ignore pattern and remains tracked).

Fix 2: browse/src/find-browse.ts — Windows .exe resolution

~30 lines: added two local helpers (isExecutable and findExecutable) and routed both candidate path lookups through them.

function isExecutable(p: string): boolean {
  try {
    accessSync(p, constants.X_OK);
    return true;
  } catch {
    return false;
  }
}

function findExecutable(base: string): string | null {
  if (isExecutable(base)) return base;
  if (process.platform === 'win32') {
    for (const ext of ['.exe', '.cmd', '.bat']) {
      const withExt = base + ext;
      if (isExecutable(withExt)) return withExt;
    }
  }
  return null;
}

Why: find-browse was using existsSync('.../browse') (exact-match, no extension). On Windows, bun --compile produces browse.exe, and Node's fs.existsSync is strict (unlike Git Bash's test -x which auto-resolves .exe on MSYS2). The compiled find-browse.exe therefore always emits ERROR: browse binary not found. Run: cd <skill-dir> && ./setup on Windows, even when browse.exe is right next to it.

Precedent: exact mirror of the equivalent helpers in make-pdf/src/browseClient.ts:89-98 (findExecutable) + make-pdf/src/browseClient.ts:159-166 (isExecutable), and the same pair in make-pdf/src/pdftotext.ts:52-61 + :117-124. Same signature, same .exe / .cmd / .bat ordering, same win32 platform guard, same accessSync(constants.X_OK) probe. The comment in make-pdf/src/pdftotext.ts:52 explicitly documents the "duplicated rather than shared because the two modules already duplicate isExecutable for compile-isolation" choice — this third copy in find-browse keeps the module self-contained for the same reason.

Daily-impact note: no SKILL.md file currently invokes find-browse (verified via grep across all SKILL.md files at any depth). The /browse skill's discovery uses bash test -x which Git Bash auto-resolves to .exe on Windows. So this is a latent bug today: real defect, no current Windows consumer. But browse/bin/find-browse (the bash shim) does exec the compiled binary as its primary path, and BROWSER.md / CLAUDE.md document find-browse as the canonical lookup. Any Node consumer that calls it would fail on Windows today.

Test plan

• bun test browse/test/find-browse.test.ts test/build-script-shell-compat.test.ts — 6 pass, 0 fail
• ./browse/dist/find-browse.exe invoked from various working directories on Windows — returns the absolute path to browse.exe instead of erroring
• After bun run build on Windows, git status no longer shows untracked bin/gstack-global-discover.exe
• Linux/macOS behavior unchanged — findExecutable only takes the .exe branch on process.platform === 'win32'; the .gitignore glob still matches the no-extension form
• Diff scope verified clean: two files, 35 insertions, 4 deletions

Out of scope

• Build-script (...) > bun-shell incompatibility — see PRs listed above
• Cross-module dedup of the findExecutable helper (two existing copies in make-pdf/; this third copy keeps the module self-contained, per the comment in pdftotext.ts:52)
• Windows CI coverage for these specific gaps

Notes

• First-time contributor here. Tell me if I've missed a convention.
• Two commits, one per logical change, per the "always bisect commits" rule in CLAUDE.md.
• Both commits trailer-credit Claude Opus 4.7 as co-author per the v1.39.2.0 precedent.