server-v0.0.6 Linux binary: ingestion dead — Cannot find module '@rivetkit/rivetkit-wasm', documents stuck in "queued" forever

[anudeepadi]

The v0.0.6 self-hosted server binary on Linux x64 accepts documents but never processes them. The workflow engine fails to load because the rivetkit wasm module isn't bundled into the compiled binary:

error: Cannot find module '@rivetkit/rivetkit-wasm' from '/$bunfs/root/supermemory-server'
GET - /api/rivet/metadata failed

Repro:

1. Fresh install on Linux x64 (Debian 12, GCE VM): curl -fsSL https://supermemory.ai/install | bash (installs server-v0.0.6), clean data dir, no prior state
2. Server boots fine, binds, prints the api key. OPENAI_BASE_URL/OPENAI_API_KEY/OPENAI_MODEL set to a working OpenAI-compatible endpoint
3. POST /v3/documents returns {"id":"...","status":"queued"}
4. Document stays queued indefinitely (checked at 1, 4, and 10+ minutes). No [Workflow]/[Extraction] log lines ever appear — on v0.0.5 the same setup logs extraction/embedding within seconds

Expected: documents progress queued → done as on v0.0.5.

Impact: v0.0.6 self-hosted is completely non-functional for ingestion on Linux. v0.0.5's boot banner also shows workflow rivet, and ingestion works there, so this looks like a bundling/packaging regression in the 0.0.6 build rather than a code change — the wasm asset just isn't inside the binary.

Env: Linux x64, Debian 12 (GCE), binary from official install script, local embeddings (Xenova/bge-base-en-v1.5).

[linear-code]

ENG-1098

[ojmarzinho]

Same on macOS, so this isn't Linux-specific.

Env: macOS 26.5.2, Apple Silicon (M4 Pro), server-v0.0.6 from the official
install script, fresh/empty data dir (no migration from a prior version),
local embeddings (Xenova/bge-base-en-v1.5), no OPENAI_* vars set.

Boot log shows the exact same failure:

error: Cannot find module '@rivetkit/rivetkit-wasm' from '/$bunfs/root/supermemory-server'
GET - /api/rivet/metadata failed

Server binds and serves HTTP 200 normally. POST /v3/documents returns
{"id":"...","status":"queued"} and the document stays queued indefinitely
(polled every 10s for 60s+). No [Workflow] or [Extraction] lines are ever
emitted. On 0.0.3 on the same machine those lines appear within seconds for
the same payload, so this matches your read that it's a packaging regression
in the 0.0.6 build rather than platform-specific code.