Stage tree-sitter.wasm into pre-init/ for relative `with { type: 'file' }`

On Windows, bun --compile bundles the wasm bytes (build verification
finds them at a known offset) but the JS-level binding from a
node_modules subpath import returns falsy at runtime:

    import wasmPath from 'web-tree-sitter/tree-sitter.wasm'
      with { type: 'file' }
    // wasmPath is undefined on Windows even though the bytes are in
    // the binary

Smoke check on the failed release confirmed it directly:

    tree-sitter smoke FAIL: pre-init published neither globalThis bytes
    nor an env path. The `with { type: 'file' }` import returned falsy.

OpenTUI's own tree-sitter assets work because they're imported via
*relative* paths from inside the package. Mirror that: copy the wasm
into cli/src/pre-init/ before `bun build --compile`, import it
relatively, remove the copy after the build.

- cli/scripts/build-binary.ts: stagePreInitWasm() copies the source
  wasm to cli/src/pre-init/tree-sitter.wasm; cleanup runs after the
  compile and is also wired to process.on('exit') so a build-script
  crash doesn't leave a multi-MB untracked file in the working tree.
  The findWebTreeSitterWasm() lookup is shared with the post-build
  verification.
- cli/src/pre-init/tree-sitter-wasm.ts: import is now `./tree-sitter.wasm`
  (relative). The file is .gitignored so dev-mode runs see no wasm here
  and fall through to init-node.ts's path-based resolution, which
  works locally because node_modules has the file.
- cli/.gitignore: ignore the staged copy.

Verified locally: build stages then cleans up the wasm,
post-build verification finds the bytes, --smoke-tree-sitter exits 0
with "tree-sitter smoke ok (wasmBinary, 205488 bytes)".

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