fix(execute): bundle backend so prod runs under Node + isolated-vm

[buremba]

Why

Execute MCP tool has been broken in prod since launch: the backend runs under Bun (JSC, partial V8 ABI shim) but isolated-vm is a V8 native addon. isolated_vm.node fails to dlopen under Bun:

undefined symbol: v8::ValueSerializer::Delegate::HasCustomHostObject

PR #427 caught this and returned RuntimeUnavailable. The hardening worked — the tool itself never ran.

PR #430 tried exec node --import tsx src/server.ts. The runtime swap mechanism worked end-to-end (verified isolated-vm + runScript() in the live image). But the actual server boot crashed because Node's cjs-module-lexer couldn't detect named exports of @lobu/core's CJS dist barrel when reached via the full server.ts import chain. Reverted in #431.

What

Per a second-opinion review, the cleaner fix is to bundle the backend at build time. esbuild resolves all workspace imports inline (using the bun condition to pick up TS source rather than the CJS dist), so Node never has to bind named imports against cross-package CJS barrels — the failure mode that broke #430 simply doesn't exist for the bundle.

• packages/owletto-backend/scripts/build-server-bundle.mjs — esbuild config that bundles workspace + relative imports, externalizes every bare specifier. ~2.4 MB self-contained ESM, ~100 ms build.
• packages/owletto-backend/package.json — build:server npm script.
• docker/app/Dockerfile — switch bun install to bun install --linker=hoisted so node_modules is flat (Node's resolver doesn't understand bun's .bun/<pkg>@<ver>/ isolated layout). Add a bun run build:server step in the builder stage.
• docker/app/start.sh — exec node /app/.../dist/server.bundle.mjs instead of exec bun src/server.ts.

Native addons stay external

isolated-vm, @sentry/*, @opentelemetry/*, pino, etc. — externalized. They need to load via Node's normal resolver because they use native bindings or require-in-the-middle hooks. The hoisted node_modules layout makes them findable from the bundle's location.

Verified

Built a local docker image (docker build -f docker/app/Dockerfile -t lobu-app-spike:bundled .) and exercised runScript via a small bundled test entry:

basic:    {success: true, returnValue: 3}
chaining: {success: true, returnValue: {slug: 'atlas', ok: true}}

Both are real V8 isolate executions inside the container, not RuntimeUnavailable.

Regression guard

The CI sandbox-runtime test added in #430 (packages/owletto-backend/src/__tests__/integration/sandbox/run-script-runtime.test.ts) stays in place. It fails loudly when isolated-vm can't load — so any future regression of the runtime contract blocks merge.

Tradeoffs

• Build adds ~5 s for the esbuild bundle.
• Hoisted layout is npm-style flat: install size similar, but matches what Node expects natively.
• If a native dep was wrongly bundled, it'll surface at boot (not silently) — easier to triage.

Test plan

• CI passes (build-test, sandbox-runtime test, all gates)
• After merge: build-images succeeds, deploy rolls cleanly, both app pods Running on the new tag
• Smoke: MCP execute returns a real result instead of RuntimeUnavailable

[github-actions]

Triage decision: needs-human

Reasons:

• File changes under docker/ infra path (docker blast radius per .github/triage-config.yml)
• Modified files: docker/app/Dockerfile, docker/app/start.sh
• Infra changes require human review due to deployment impact

Next: @buremba assigned for manual review — Docker bundling changes for Node + isolated-vm compatibility in production