fix(deps): dedupe nested msgpackr instance under rocksdb-js

[kriszyp]

Summary

main is red on Docker Image Smoke Test (both linux/amd64 and linux/arm64) because
build-tools/check-shrinkwrap-pins.mjs rejects the install: rocksdb-js loads a nested
msgpackr@2.0.6 instead of sharing the root one.

package-lock.json carried a
node_modules/@harperfast/rocksdb-js/node_modules/msgpackr entry even though root msgpackr
and rocksdb-js's own msgpackr dependency are pinned to the identical exact 2.0.6
(package.json:227,
package-lock.json:2504
pre-fix) — a pure hoisting artifact, not a version conflict. It was added incidentally by
2e65550 (#2147), an unrelated REST-pagination PR that happened to bump
@harperfast/rocksdb-js to 2.8.0; that commit's lockfile diff only ever adds the nested
entry, nothing else. The nested copy is exactly what
verifyRocksDbDependencyAlignment in build-tools/check-shrinkwrap-pins.mjs
exists to catch: msgpackr carries per-instance structure state, so two module instances
sharing one database is a decode-corruption risk class, not a cosmetic duplicate — the check
is correct and is unchanged by this PR.

Fix is a single 9-line lockfile deletion —
the exact inverse of the culprit commit's diff — removing the nested entry so npm hoists
rocksdb-js's msgpackr dependency to the single root instance, matching what the exact pins
already declare.

Verification

• rm -rf node_modules && npm ci from the fixed lockfile: no
  node_modules/@harperfast/rocksdb-js/node_modules/msgpackr directory, and npm ci does not
  reintroduce it (proves the fix is self-consistent under npm's own resolver, not just a hand
  edit of the lock text).
• require.resolve('msgpackr') from the root and via require.resolve('msgpackr', { paths: [require.resolve('@harperfast/rocksdb-js')] }) return the identical file path.
• Reproduced the Docker image's install flow locally (no docker binary available in this
  environment): npm shrinkwrap → build-tools/prune-shrinkwrap-dev.mjs →
  build-tools/prune-shrinkwrap-react-native.mjs → extracted into a scratch dir → npm install --omit=dev --ignore-scripts --no-audit --no-fund (mirrors the Dockerfile's
  global-install step) → ran build-tools/check-shrinkwrap-pins.mjs directly against it —
  this is the exact check that is red in CI and it now exits 0: shrinkwrap pin matches (exact manifest spec): @harperfast/rocksdb-js@2.8.0 matches the packed pin.
• npm run build (tsc) — clean.
• npx mocha unitTests/build-tools/checkShrinkwrapPins.test.mjs — 15/15 passing.
• Diff is exactly package-lock.json | 9 deletions(-) against main — no other files
  touched.

For the human reviewer

Independent pre-push review (codex + Harper domain adjudication; Gemini/Cursor legs did not
produce coverage this round — see receipt) came back LGTM with one minor, non-blocking
durability observation, deliberately left out of this PR as out of the stated task scope
(explicitly asked to keep the diff to package-lock.json only):

• The dedupe currently holds only because root msgpackr and rocksdb-js's own msgpackr spec
  happen to be pinned to the identical exact version. check-shrinkwrap-pins.mjs already
  re-verifies both that equality and the no-nested-copy invariant on every push/PR that
  touches package.json or package-lock.json — which is exactly the mechanism that caught
  this regression — so there is live enforcement today. A stronger, more mechanical guarantee
  (e.g. a scoped overrides entry pinning rocksdb-js's msgpackr to $msgpackr) would remove
  the dependency on the two pins being kept in sync by convention, at the cost of an
  overrides field in package.json. Leaving that decision to a maintainer rather than
  expanding this PR.
• node_modules/lmdb/node_modules/msgpackr@1.12.1 remains nested (lmdb's ^1.11.2 range
  can't accept 2.0.6, and Harper's RecordEncoder/StructonEncoder — the actual
  record-encoding hot path, both LMDB and RocksDB — is built from the root msgpackr
  regardless of engine, so this pre-existing duplicate is unrelated to the invariant the check
  protects). No action taken; flagging so it isn't mistaken for a miss.

Framing-Verdict: not applicable — mechanical lockfile-only fix restoring an existing,
already-declared invariant (no new API surface, no cross-layer boundary, no new shared
behavior); harper-engineering-guidelines step 6 planning gate does not trigger.

_{Review-Coverage: authored=claude; ran=codex; adjudicated=domain; blocked=gemini(auth),cursor-composer(failed); declined=cursor-grok; rounds=1 @ 7ff3f79}

_{Human-Review-Need: 3 (decisions: enforce-via-overrides-vs-lockfile-only, leave-lmdb-nested-copy, no-verification-added) @ 7ff3f79}

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.