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>