Provision Bun corpus dependencies for reproducible full-VM parity runs

Problem

The copied Bun corpus declares verdaccio 6.0.0 in packages/runtime/test/bun-corpus/package.json and bun.lock, but packages/runtime/test/bun-corpus/node_modules is absent. The reference /Users/chris/Code/bun checkout also currently lacks node_modules/verdaccio.

As a result, both Home full-VM execution and the pinned Bun reference runner fail while loading test/harness.ts at require.resolve("verdaccio/bin/verdaccio") before lifecycle tests register. This is an environment/dependency provisioning failure, not a runtime assertion failure.

Reproduction

• HOME_NATIVE_VM=1 HOME_CORPUS_FULL_VM=1 home-debug test packages/runtime/test/bun-corpus/cli/install/bun-install-lifecycle-scripts.test.ts
• pinned Bun test /Users/chris/Code/bun/test/cli/install/bun-install-lifecycle-scripts.test.ts

Both report that verdaccio/bin/verdaccio cannot be found.

Acceptance criteria

• Provide a reproducible, lockfile-pinned way to provision the Bun corpus test dependencies for local and CI parity runs.
• Full-VM Home and pinned-Bun reference runs can load the unchanged upstream harness and start the real Verdaccio child.
• No fixture rewrites, manual symlinks, implicit global packages, or relaxed assertions/workloads.
• Document the command used by parity validation.

Related: #66, #202. The routed Home corpus runner now passes the unchanged lifecycle and config-version files 63/63; this issue is specifically about making the independent real-harness/full-VM axis reproducible.

Most of this works today; the remaining scope is the two file: dependencies

scripts/provision-corpus-deps.sh (f2ee14f4d) does the lockfile-pinned install this issue asks for:

scripts/provision-corpus-deps.sh     # bun install --frozen-lockfile in the corpus

On Darwin arm64 it installs 2,896 packages in ~20 seconds and leaves bun.lock byte-identical — the script fails if that file is modified, since it is upstream's. verdaccio, happy-dom, strip-ansi, detect-libc and body-parser are all present afterwards, and js/node/vm/happy-dom-vm-16277.test.ts goes from failing-to-load to passing. Whatever made verdaccio unavailable on the reference checkout, it was not the corpus manifest or lockfile: they resolve cleanly.

What still fails — exactly two packages:

ENOENT: failed to link package: bun-plugin-svelte@../packages/bun-plugin-svelte
ENOENT: failed to link package: react@../node_modules/react

Both are file: specifiers written against Bun's own repository layout, where test/'s siblings are <bun>/packages/bun-plugin-svelte and <bun>/node_modules/react. Home keeps the corpus at packages/runtime/test/bun-corpus/, so ../packages/... and ../node_modules/... resolve to packages/runtime/test/packages/ and packages/runtime/test/node_modules/, neither of which exists.

Home does already mirror the plugin, at packages/runtime/upstream/packages/bun-plugin-svelte.

The acceptance criteria rule out the two obvious ways to connect them — a symlink, or editing the corpus's package.json — which leaves a repository-layout decision that is yours rather than mine:

1. Give packages/runtime/test/ a package.json declaring a workspace, so react hoists to packages/runtime/test/node_modules/react where the corpus manifest already looks for it, and place (or generate) the plugin at packages/runtime/test/packages/bun-plugin-svelte from the existing mirror.
2. Or move the corpus so its parent genuinely is the sibling layout the unchanged manifest expects.

Either satisfies "no fixture rewrites, manual symlinks, implicit global packages, or relaxed assertions"; the first is smaller but adds a workspace root, so I have not picked one unilaterally.

The known consumers are bundler/bun-plugin-svelte fixtures and the React integration tests. Nothing in js/node needs either package — that whole directory now provisions and runs, measured in #621.

Provisioning is complete on main via aace34384.

• scripts/provision-corpus-deps.sh now reproduces the repository layout required by the unchanged corpus: parent React is lock-pinned, and the tracked Svelte plugin mirror is copied into the exact sibling path expected by the upstream file: specifier.
• Both parent and corpus installs use frozen lockfiles, both lockfiles are checked byte-for-byte before/after, and required manifests are verified. Repeated runs are idempotent.
• No upstream corpus manifest, lockfile, fixture, assertion, timeout, or workload was changed; no symlink or global dependency is used.
• The unchanged React/Markdown consumer is 68/68 in Home Debug and ReleaseFast; the Svelte bundling consumer is 1/1 in both modes. The pinned Bun consumer control is 70/70.
• The exact full-VM lifecycle command now loads the unchanged harness, starts the real Verdaccio child, and executes all 60 registered tests instead of aborting during dependency resolution. Home currently reports 24 pass / 36 implementation failures. The dominant failure is the still-noop npm_manifest_test_helpers.parseManifest internal binding and is being fixed as runtime parity work, outside this provisioning issue.
• The pinned canary likewise loads the harness and executes all 60 tests. That binary reports 20 pass / 40 fail because its release build does not expose bun:internal-for-testing; this is recorded as a control-binary limitation, not claimed as a passing parity baseline.

Reproduction:

scripts/provision-corpus-deps.sh
HOME_NATIVE_VM=1 HOME_CORPUS_FULL_VM=1 ./zig-out/bin/home test packages/runtime/test/bun-corpus/cli/install/bun-install-lifecycle-scripts.test.ts
/Users/chris/Code/bun/build/release/bun test packages/runtime/test/bun-corpus/cli/install/bun-install-lifecycle-scripts.test.ts

The dependency-provisioning acceptance criteria are satisfied. Remaining lifecycle behavior stays tracked under #66 and the native installer scope in #518; the spawned Svelte HTML server reachability gap is isolated in #641.