Use argv[0] (not execPath) to find sibling wasm — pre-init fix on Windows

Round 6's diagnostic dump on Windows revealed why
existsSync(siblingPath) was returning false even though the wasm
file was right next to the binary:

    [smoke diag] execPath=D:\a\codebuff\codebuff\cli\bin\codebuff.exe
    [smoke diag] siblingExists=true   (in main())
    [smoke diag] globalThis wasmBinary bytes=0   (set by pre-init)

    Aborted(Error: ENOENT: no such file or directory, open
      'B:\~BUN\root\tree-sitter.wasm')

Pre-init runs at module load. main() runs later. The diag is in
main(), which sees execPath as the disk path. But the ENOENT line
shows what pre-init actually saw: `B:\~BUN\root\tree-sitter.wasm`
— the *bunfs internal* path. So inside a bun --compile binary on
Windows, `process.execPath` returns the bunfs path during early
module evaluation and only switches to the disk path later. Pre-init
silently bailed because that bunfs sibling doesn't exist.

Switch pre-init to use process.argv[0] instead. argv[0] is the path
the binary was *invoked with* — always a real disk path, not a bunfs
internal one. Try execPath as a fallback for environments where
argv[0] is somehow exotic. Whichever yields an existing sibling wins.

Verified locally on macOS where execPath was already the disk path:
build copies wasm to bin/, pre-init finds and reads it,
--smoke-tree-sitter exits 0.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: jahooma

cli/src/pre-init/tree-sitter-wasm.ts

@@ -20,16 +20,29 @@
 // zero bundler involvement.
 
 import { existsSync, readFileSync } from 'fs'
-import { dirname, join } from 'path'
+import { dirname, isAbsolute, join, resolve } from 'path'
 
-// Sibling path: same directory as the running binary. Works for both
-// production binaries (where the downloader places tree-sitter.wasm
-// next to the executable) and dev runs (path won't exist, falls
-// through to init-node.ts's path-based resolution which finds the
-// node_modules copy).
-const siblingPath = join(dirname(process.execPath), 'tree-sitter.wasm')
+// Where to look for the sibling tree-sitter.wasm. We can't just use
+// `dirname(process.execPath)`: at pre-init time inside a bun --compile
+// binary on Windows, `process.execPath` returns the *bunfs* internal
+// path (`B:\~BUN\root\<binary>.exe`) rather than the on-disk path of
+// the .exe the user invoked. By the time main() runs it switches to
+// the disk path, but pre-init has long since bailed out.
+//
+// Try several sources in order; the first whose sibling .wasm exists
+// wins. argv[0] is normally the path the binary was invoked with —
+// always a real disk path, never bunfs. execPath is kept as a fallback
+// for environments where argv[0] is something exotic.
+const candidates = (
+  [process.argv[0], process.execPath] as Array<string | undefined>
+)
+  .filter((p): p is string => typeof p === 'string' && p.length > 0)
+  .map((p) => (isAbsolute(p) ? p : resolve(p)))
+  .map((p) => join(dirname(p), 'tree-sitter.wasm'))
+
+const siblingPath = candidates.find((p) => existsSync(p))
 
-if (existsSync(siblingPath)) {
+if (siblingPath) {
   // Tell init-node.ts (in code-map / the SDK bundle) where the wasm
   // is. The locateFile callback there will hand this path to
   // emscripten, which fs.readFile's it.