Consider `bun build --compile` for `allium-lsp` distribution

[tburny]

Suggestion to evaluate replacing the allium-lsp build pipeline's final step with bun build --compile to ship the LSP as a standalone binary instead of a Node tarball.

Not asking for a full migration to Bun as a package manager — just the compile step.

Current shape

Per scripts/build-release-artifacts.sh and packages/allium-lsp:

TypeScript → esbuild → dist/bin.js + WASM blob → allium-lsp-{version}.tar.gz
                                                  (requires Node 20 at runtime)

Users install the LSP by unpacking the tarball and pointing their editor at node dist/bin.js.

Proposed shape

TypeScript → bun build --compile --target=bun-{platform} → standalone binary
                                                            (no runtime dep)

WASM embedding via Bun.embeddedFiles so allium_wasm_bg.wasm ships inside the binary.

Why

1. Removes Node 20 as a runtime dep for LSP users. vscode-languageserver only uses stdio, so Bun's Node compatibility shouldn't be a blocker — but worth verifying.
2. Unifies release artifacts. release-artifacts.yml already produces four Rust CLI binaries (x86_64/aarch64 × Linux/Darwin). The LSP would join the same shape instead of being a special-cased tarball. Homebrew formula updates also simplify.
3. End-user install simplifies to "download binary, chmod +x" — same as the CLI.
4. Nix packaging collapses. A standalone binary is a stdenv.mkDerivation wrapping bun build --compile, vs buildNpmPackage + wasm-pack staging + wasm-bindgen-cli version pinning. (Filed separately as the flake issue.)

What stays unchanged

• package.json, package-lock.json, npm install for contributors — Bun is release-only.
• VS Code extension build path — VS Code runs the extension in its own Electron/Node, so extensions/allium keeps its current esbuild bundle.
• WASM build — still wasm-pack, just consumed by Bun instead of Node.
• Tests, lint, dev workflow — untouched.

CI gains a Bun install step in the release job only. Contributors don't need Bun locally.

Tradeoffs

Cost	Notes
Binary size: ~50–90 MB per target	vs ~2 MB JS bundle + user-installed Node. Matters less for users who don't already have Node 20.
New toolchain in CI	Bun is in nixpkgs / Homebrew / official installer. Single install step.
Bun stability on aarch64-linux slightly trails x86_64-linux	GA for >1 year; should be fine in practice but worth a smoke test.
Verification needed: vscode-languageserver under Bun	Stdio-only, no exotic Node APIs in the LSP — low risk but not zero.

Suggestion

A timeboxed spike: pick one target (bun-linux-x64), produce a --compile'd LSP binary, run it against the existing test cases, and decide. If it works, expand to the other three targets in release-artifacts.yml. If vscode-languageserver chokes under Bun, the spike is the cheapest way to find out.

Happy to send the spike PR if there's interest.