fix: rewrite CLI to use esbuild bundle output

[garythebat]

Summary

Rewrites src/kiri/run/cli.js to use the pre-built esbuild bundles (kiri-eng.js + kiri-work.js) instead of the removed gapp.js eval-based loader. Same CLI interface, same in-process Worker bridge pattern, same single-threaded execution model as the original.

Follows up on #478 and #479 (Docker + esbuild build fixes) which made the bundles reliable to produce. With those merged, the CLI can consume the bundles directly as read-only build output.

Commits

1. fix: update CLI to use esbuild bundle output (cd944a2) — the core rewrite
2. fix: correct setMode order and setProcess variable shadowing (c5e0750) — call setMode() before setDevice()/setProcess() so mode defaults land first; rename local process to procset to avoid shadowing Node's global process (was silently breaking process.exit/stderr under ESM)
3. fix: WASM path resolution, process variable fix, document CAM limitation (cca1dec) — intercept fs.readFileSync to redirect .wasm lookups to src/wasm/ so manifold-3d loads correctly; suppress Aborted() exceptions cleanly from optional WASM modules; explicitly set controller.threaded:false after setMode to prevent the mode switch from re-enabling the pool

What works

• FDM, LASER, SLA modes — all slicing via the in-process Worker bridge. Tested on Raspberry Pi 5 (ARM64) with a cube STL + Ender 3 FDM config, producing valid gcode.
• Same CLI flags as the original (--model, --device, --process, --output, --tools, --verbose).
• Clean stdout (gcode pipeable); stderr for diagnostics when --verbose.

What's explicitly deferred

CAM mode is documented at the top of cli.js as limited. The in-process Worker bridge short-circuits the parallel toolpath pool that CAM relies on. Wiring CAM up properly needs Node's worker_threads behind the same globalThis.Worker shim — meaningful scope best handled as a follow-up PR so this one stays reviewable.

The CAM config templates (src/cli/kiri-cam-{device,process,tools}.json) are kept in-tree so the follow-up can focus on just the worker pool.

Testing

Run any of:

node src/kiri/run/cli.js \
  --model your.stl \
  --device src/cli/kiri-fdm-device.json \
  --process src/cli/kiri-fdm-process.json \
  --output out.gcode

Or the LASER/SLA equivalents with matching device/process JSON. Works on Node 22 (Docker image and host).

Platform notes

• Tested on ARM64 (Raspberry Pi 5) and x86_64.
• Needs the esbuild bundles present (npm run pack-prod after install) — fix: add missing build steps and update Node in Dockerfile #478 ensures the Dockerfile does this automatically.

[garythebat]

Marking as draft — still completing tests before requesting review. Will mark ready once we've validated FDM/LASER/SLA outputs against a full test matrix.