Native install: frozen corpus lockfile rejected despite identical serialization

Refs #66, #703 and #714.

Home rejects the unchanged, pinned Bun corpus lockfile with lockfile had changes, but lockfile is frozen. Pinned Bun accepts the same lockfile in a separate isolated control. This prevents native Home provisioning from reaching the AWS extraction failure tracked in #714.

Build source: fcb3461. Home executable SHA-256: 3b9412bb55f7c2750c15d6abf1761910924e32e8ebc09683583e5e4eb3838cfd. Real native HTML parser linked; build and explicit docs: 49/49 steps.

The first native frozen corpus provisioning exited 1. Isolated controls preserve the corpus package.json, bun.lock, bunfig.toml, and the two relative local dependency targets. install --lockfile-only --ignore-scripts --verbose serialized identical bytes under both runtimes (SHA-256 ed2b9b145603d661da89ba15cec4544a09f06eff4c88debe2f83452d555ca351). A subsequent install --lockfile-only --frozen-lockfile --verbose exited 1 under Home and 0 under Bun. Both clean from 1,627 packages to 1,627 packages. These are diagnostic controls, not an accepted alternative provisioning route.

Verbose comparison diagnostics are being built in e36a99a to identify the differing in-memory fields. Do not remove frozen validation, rewrite the corpus pins, or manually populate node_modules. Completion requires the native frozen install and content validation to succeed, plus regression controls that continue rejecting actual lock changes.

Evidence is retained outside disposable worktrees in .git/bun-port-evidence/recovery-20260908/lockfile-clean-controls/, including exact commands, first exit statuses, SHA-256 hashes and full logs.

A second integrity fix is pushed in 9fbd927: provisioning compares SHA-256 of both lockfile inputs rather than Git porcelain status. A private wrapper regression proves the former check accepted further mutation of an already-dirty lockfile; the corrected check accepts unchanged input and rejects mutation. This does not change the corpus pins or resolve #715 by itself.

Source inspection identified a candidate for #715: SlicedString.external() computes prerelease hashes through String.stringHash() (current Zig Wyhash), while cloning an external/long tag recomputes through String.Builder.stringHash() (Bun Wyhash11). Upstream uses Wyhash11 in both paths. The corpus contains a long bun-types canary prerelease. The verbose diagnostic build and a minimal release/short-prerelease/long-prerelease comparison against pinned Bun will confirm the actual failing field before applying the hash fix.

Confirmed the cause and pushed the fix to origin/main in 6053c6c71.

The verbose native build (e36a99a, 46/46 steps) identifies the first full-corpus mismatch as @verdaccio/config: the cleaned and original resolution both print 6.0.0-6-next.76, but compare unequal. A minimal registry-free fixture proves the boundary: Home and Bun accept 1.0.0 and 1.0.0-alpha.1; Home rejects 1.0.0-canary.20250226T140704 while Bun accepts it. The native regression also reached and passed its real dependency-removal rejection controls before failing on the long prerelease. These first outcomes are retained.

Parsed external strings used current Zig Wyhash, while cloning long tags recomputed Bun Wyhash11. String.stringHash now uses the same upstream Wyhash11 helper as the builder. This preserves actual equality, rather than suppressing frozen checks. The focused Zig cloning regression passes, checking prerelease/build hashes, copied contents, and rejection of a different prerelease. Pickier and Zig formatting checks pass. The broad standalone semver test attempt could not compile its formatting tests without the native bun module; it is retained as a test-configuration failure, not a pass.

A fresh production build and a batched native prerelease/create/original-semver/frozen-provisioning run are underway. #715 remains open until the real native frozen install is verified; #714 remains open until AWS archive contents are checked. No dependency lock changes or manual extraction have been used.

Verified the production fix at 6053c6c. Build: 46/46 steps. Home executable SHA-256: fbc3cfe5af5e1c020e4aad2e6d4bae74584afbd87de970b1134e3ac653da9e15.

Native frozen prerelease regression passes all release/short-tag/long-tag/build-tag cases, with real dependency-removal rejection controls. Native create regression also passes. The original semver corpus reports 25 registered passes and zero failures.

The exact native frozen corpus provisioning succeeded. Both pinned lockfiles remain byte-identical. All 5,945 installed AWS CDK 2.148.0 regular files match the verified pinned tarball, with zero missing or different files. The subsequent corpus source audit retains 12,996 tracked entries: 12,990 identical regular files, five identical symlinks, and only the known expectations.txt metadata difference; no missing or mode differences.

Full logs, first failures, hashes, and the updated baseline are pushed in 65d0e916e. This completed the existing partially populated dependency tree; it is not a cold-install benchmark. The first pinned-Bun AWS extraction failure remains retained and is not replaced by Home's successful outcome.

This resolves the native frozen-lockfile defect tracked here. Frozen checks remain enabled; no pins were changed or packages manually extracted.