slice install — lockfile-aware, scripts-off dependency install recorded in the CAS manifest #34

Summary

Slice relies on an external package manager (bun install / npm install) to populate node_modules, and slice pack / slice run then bundle from disk. There is no slice install, no lockfile awareness, and no way for slice.toml to declare dependencies.

Why it matters

Every competing runtime that targets "run this project" (Deno, Bun) ships install. For Slice's positioning as a multi-tenant / embedded runtime the need is slightly different but still real:

• A platform operator who receives a tenant's package.json + lockfile must be able to produce a .cas deterministically without trusting arbitrary lifecycle scripts or network access from the tenant.
• Reproducibility: the CAS is content-addressed, but its inputs (which node_modules tree was on disk) currently are not recorded.

Proposal (scoped — not a full npm clone)

1. slice install [--frozen] [--ignore-scripts]: read package.json + bun.lock / package-lock.json / pnpm-lock.yaml, fetch tarballs from the registry (or a configured mirror), verify integrity hashes, lay out node_modules (flat/hoisted is sufficient since Slice bundles anyway). Lifecycle scripts off by default — this is the security feature.
2. Record the lockfile digest and resolved package set inside the CAS manifest so slice inspect can show exactly which dependency versions a bundle contains.
3. slice.toml [dependencies] as an alternative to package.json for projects that are Slice-first.
4. Optional: a content-addressed global store (~/.slice/store) so repeated tenant builds share fetched tarballs.

An interim step that costs very little: document the supported path explicitly (bun install --frozen-lockfile --ignore-scripts → slice pack) and have slice pack emit a warning when node_modules is absent instead of failing late inside the bundler.