Summary

Follow-up to #109 (NodeRuntime nodeModules resolution). Closes the gap a user hit on 0.3.1-rc.2: the JS SDK NodeRuntime.create({ nodeModules }) path still surfaced _resolveModule returned non-string for '<pkg>'.

Two things were missing on main:

1. The actionable error never merged. The reword that turns the cryptic _resolveModule returned non-string into a real "module not found" message was authored but unmerged, so users still saw the internal-type-error-looking message.
2. The regression test only covered a plain layout. test+docs: host-mounted node_modules resolution (#109) #113 projects a host node_modules of real package directories. Real installs are not plain: pnpm/yarn lay node_modules out as symlinks into a .pnpm store, and that symlinked layout is what the TypeScript nodeModules option actually produces. It was never tested end-to-end.

What this does

• Reword the not-found error (crates/v8-runtime/src/execution.rs): name the importer, state it as not-found with remediation. Also call out the host-mounted node_modules case explicitly: a host_dir mount confines reads to its root (anchored openat2(RESOLVE_BENEATH)), so a package symlinked out of the mounted tree (pnpm/yarn workspace or file: deps linking to the workspace root or an external store) is not followed and surfaces as not-found. Remediation: mount a directory that contains every symlink target (e.g. the workspace root), not the leaf node_modules.
• End-to-end symlink regression (crates/sidecar/tests/node_modules_symlink_resolution.rs): boots a real VM, projects a pnpm-style node_modules (top-level relative symlinks into .pnpm, plus a scoped package) at guest /tmp/node_modules via the same host_dir mount the TS nodeModules option emits, and asserts both a plain and a scoped symlinked package resolve from guest import.
• Main-only ESM test (crates/execution/tests/module_resolution.rs): a bare package whose package.json has main but no exports map (separate code path from exports).
• Docs (features/module-loading): note the escaping-symlink confinement and the mount-the-workspace-root fix.

Not changed (by design)

The mount still confines reads to its root. We do not follow symlinks that escape the mounted tree: a malicious package installed by the client could plant a symlink to an arbitrary host path, and the read-only mount must not become a host-fs read primitive for guest code. The correct fix for workspace layouts is a wider mount root, which the docs and error now state.

Verification

• cargo test -p secure-exec-sidecar --test node_modules_symlink_resolution → pnpm-symlinked plain + scoped packages resolve from guest import.
• cargo test -p secure-exec-execution --test module_resolution → 37 passed (incl. faithful_pnpm_symlink_layout_resolves_via_realpath_walk, symlinked_package_escape_is_not_resolved).
• Reproduced the user's path against published [email protected]: plain, transitive, CJS require, createRequire, pnpm-symlink, exports-map, and scoped layouts all resolve; the only repros of the exact error are (a) hostPath pointed at the wrong directory and (b) a symlink escaping the mount root.

Refs #109.