Move sibling-wasm lookup from pre-init to init-node's locateFile callback

Round 8 (argv[0] in pre-init) failed on Windows for the same reason
round 7 (execPath in pre-init) did:

    [pre-init diag] argv[0]=bun                              # not a path!
    [pre-init diag] execPath=B:\~BUN\root\<binary>.exe       # bunfs

Pre-init runs at module evaluation time. Inside a bun --compile binary
on Windows during that phase, both `process.argv[0]` and
`process.execPath` lie:

 - argv[0] is `"bun"` (the runtime name), not a real path
 - execPath is the *bunfs internal* path (`B:\~BUN\root\...`),
   not the disk path of the .exe

Both stabilize to real paths by the time main() runs (round 7's main()
diag confirmed that), but the SDK's eager Parser.init has already
fired by then with bad path data.

The fix: do the sibling-file lookup *inside the locateFile callback*
in code-map's init-node.ts. emscripten calls that callback during
Parser.init's async work, after process.execPath has stabilized to
the disk path. By then, `dirname(process.execPath) +
'tree-sitter.wasm'` resolves correctly.

- packages/code-map/src/init-node.ts: add a sibling-of-execPath
  check between the existing scriptDir fallback and the require.resolve
  fallback. Improves the thrown-error message to include the
  attempted execPath dir so future failures are easier to diagnose.
- cli/src/pre-init/tree-sitter-wasm.ts: keep the eager lookup as a
  best-effort fast path (it works on macOS/Linux where execPath is
  the disk path from module-load); on Windows it silently no-ops and
  the locateFile callback handles things lazily. Diagnostic dump
  remains gated on --smoke-tree-sitter so we can see what each phase
  thinks the paths are.

The SDK dist also needs rebuilding so the bundled init-node.ts copy
picks up this change — included in the diff.

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