Lock built-in JavaScript runtimes

[sergeivaskov]

Summary

• ship package-owned npm_ex lockfiles for the built-in Svelte, Solid, and Tailwind runtimes
• install exact direct versions through a shared Volt.JS.Runtime.PackageSet
• include the lockfile digest in named runtime identity and provide a lock update script

Problem

Volt's built-in framework/compiler runtimes currently resolve version ranges independently of an application's package.json and npm.lock. For example, the Svelte plugin requests ^5.0.0, while Tailwind requests ^4.3.0 and *. The runtime installer already supports a package-owned lockfile, but these built-in callers do not pass one, so a fresh build can select a different transitive graph without an application lockfile change.

Design

Volt.JS.Runtime.PackageSet keeps each built-in runtime's exact package set and packaged lockfile together. Both direct installation and named runtime creation use that same lock. Named runtime signatures hash the lock contents rather than depending on a path, so changing a packaged graph cannot silently reuse a runtime created from an older lock.

scripts/update_runtime_locks.exs regenerates all locks, or one selected package set with --only, from the exact versions declared by the owning module.

Verification

• mix test: 609 tests, 0 failures
• fresh-cache package-set integration tests install byte-identical packaged locks
• the built Hex archive contains priv/npm/{svelte,solid,tailwind}.lock
• two independent clean Ubuntu amd64 consumer builds produced identical runtime locks and production assets