fix(cli): add Node-compatible bin wrapper for npm publish

[braden-w]

Problem

npm publish strips .ts files from the bin field. Our CLI's bin pointed to ./src/bin.ts, so after publish, npx epicenter and bunx epicenter would fail — npm silently removes the bin entry from the published package.

Solution

Added bin/epicenter.mjs — a Node-compatible wrapper that handles three runtime scenarios:

Running under Bun (the happy path): The wrapper detects typeof Bun !== "undefined" and directly imports ../src/bin.ts. Zero overhead.

Running under Node, Bun installed: The wrapper detects it's in Node, checks if Bun is on PATH via spawnSync("bun", ["--version"]), and re-execs itself with Bun. This handles npx epicenter on machines that have both runtimes.

Running under Node, no Bun: Prints a clear error message with install instructions and exits.

Why #!/usr/bin/env node instead of #!/usr/bin/env bun

npx on Windows ignores shebangs and always invokes with Node. A #!/usr/bin/env bun shebang would produce a cryptic OS-level error (bun: No such file or directory) on machines without Bun. Using node as the entry point guarantees the script always launches, then makes an intelligent decision about how to proceed.

Why not compile to JS

The CLI imports .ts files and uses Bun-specific APIs (bun:sqlite). Compiling to JavaScript wouldn't help — the output still can't run on Node. Bun is a genuine runtime requirement, not a build preference.

Prior art

This is the established pattern for Bun-first CLIs on npm:

• trekker — same #!/usr/bin/env node + Bun detect + re-exec
• pensar — same pattern with ENOENT handling
• t1code — same pattern

Tested

Scenario	Result
bun epicenter.mjs --help	✅ Direct import, no subprocess
node epicenter.mjs --help	✅ Re-execs with Bun
Node without Bun on PATH	✅ Prints install instructions, exits 1

Changelog

• Fix CLI binary not working after npm publish