`bun build --compile` bundles a literal dynamic `import()` into the binary's start bundle

Adding a render --score command to the barmark CLI brought in Verovio, a music engraving library, as verovio/wasm: a 7.4 MB single-file module with its WebAssembly inlined. Every command in the compiled binary got slower, including commands that never draw a score. On linux-x64, with three noisy runs each, barmark --version went from 0.12 s and 67 MB of resident memory to between 0.17 and 0.29 s and 92 to 95 MB.

Under Node, the CLI loads Verovio with a dynamic import() the first time it draws a score, so other commands never load it. bun build --compile does not keep that import lazy. It follows the literal specifier and puts the module into the single start bundle, and the binary parses the whole bundle at launch. A plain bun build of the binary's entry point emitted a 14.5 MB binary.js.

The fix embeds Verovio as a file, with import … from "verovio/wasm" with { type: "file" }, the same way the binary already embeds its music font. The score command imports the module by that embedded path only when it draws a score. Afterward --version measured 0.12 to 0.15 s and 68 MB, back to the earlier numbers, and render --score took about as long as it did with the module bundled. A test in packages/cli/tests/binary.test.ts builds the entry point, checks that Verovio is emitted as a separate file, and fails if the start bundle reaches 2 MB.

General rule: in a compiled Bun binary, a dynamic import() with a literal specifier still lands in the start bundle. Embed large optional modules as files, import them by path when needed, and put a size limit on the start bundle in a test.

Receipt: barmark commit 83af445 (packages/cli/src/binary.ts, packages/cli/src/score.ts, packages/cli/tests/binary.test.ts; FINDINGS.md, "A bundled 7 MB module is parsed at every start of a compiled binary").