perf(cli): carry lock hashes over instead of refetching the whole graph

[Kamirus]

Follow-up to #713, stacked on its branch.

Every lock regeneration asked the registry for the file hashes of all resolved packages (getFileHashesByPackageIds over the full id list). It is a single batched canister call, but its payload scales with the whole dependency graph — after #713 removed manifest re-downloads, this was the dominant per-add network cost, paid on every mops add, remove, update and sync.

The same immutability argument as #713 applies: a published version's file hashes can never change, so hashes of packages already present in the lock are carried over verbatim, and the registry is queried only for packages new to the lock. Two consequences worth naming:

• mops add x queries hashes for x and its newly-locked transitives only — network is now proportional to the change, not the graph.
• mops remove regenerates the lock with zero registry queries.

Recovery semantics are preserved deliberately

mops install --lock update (any explicit --lock update) bypasses the carry-over and refetches every hash, so it remains the one command that repairs a lock with corrupt hashes. This split also has a diagnostic consequence: after an implicit regeneration a hash mismatch can be either a locally edited .mops/ file or a corrupt carried-over hash, so the post-regeneration error no longer claims a local edit with certainty on that path — it offers both fixes:

Mismatched hash for core@1.0.0/src/Array.mo
.mops/core@1.0.0/src/Array.mo does not match the lock.
If you have not modified files under .mops/, a hash carried over from the previous lock may be corrupt.
Run `mops install --lock update` to refresh hashes from the registry, or delete the `.mops/core@1.0.0` directory and run `mops install` to restore the package.

The confident "your local copy has been modified" message still appears when the lock was fully refetched (--lock update), where it is provably true.

One behavior change: a lock whose hashes were corrupted no longer gets silently repaired as a side effect of the next mops add — the corruption is carried, detected, and reported with the fix (asserted by the new test). Silent rewriting erased the evidence; pnpm errors on integrity mismatch the same way.

Also folds away a redundant resolve: updateLockFile derived package ids via a second resolvePackages() walk; they now come from the resolution it already ran.

What is unchanged

--lock check, lock format, and hash verification (every .mops/ file is still hashed and compared on mutating commands) are untouched — this PR changes where the lock's expected hashes come from, not what gets checked. Locks from older CLIs and v1/v2 locks get no carry-over (full refetch), same as today.

🤖 Generated with Claude Code

[github-actions]

Cursor AI review

👍 APPROVE — looks safe to merge

Category	Assessment	Details
Summary	✅	Lock regeneration carries immutable per-package file hashes from the prior v3 lock and queries the registry only for newly locked packages; explicit --lock update still full-refetches. Docs, changelog, and a regression test cover the intentional no-silent-heal behavior.
Code Quality	✅	Reuses resolvedDeps from the existing resolveDepsAndGraph walk instead of a second resolvePackages(); shares tolerant lock parsing via readLockFileTolerant for graph + hash carry-over.
Consistency	✅	Matches existing force = !!lock / defaultLock: "update" patterns in add/remove/update/sync; changelog under ## Next and docs/docs/10-mops.lock.md updated; skill’s --lock update recovery guidance remains accurate.
Security	✅	Traced checkIntegrity → updateLockFile (force gates carry-over) → checkLockFile (still hashes every locked .mops/ file). Fail-closed on corrupt carried hashes; --lock update recovery preserved; v1/v2/missing locks still full-refetch via readLockFileTolerant.
Tests	✅	New case in cache-resilience.test.ts asserts carry-over of a tampered hash on add, loud failure, and recovery via install --lock update. Existing cli.test.ts covers --lock update corrupt-hash rewrite and local-edit messaging.
Maintainability	✅	Small, localized change with clear invariants in comments; docs explain recovery. Stale top-of-checkLockFile comment is leftover wording only, not a behavior defect.

Verdict

Decision: APPROVE
Risk: Low
Reason: Integrity-path optimization is sound under published-version immutability: verification still runs, corrupt carry-over fails loudly, and explicit --lock update remains the full refetch recovery path with test coverage.

---

Generated for commit c2b0860

[automation-sa-sre]

Automated approval: the AI review verdict for e88c7a6 is APPROVE. See the "Cursor AI review" comment for details.

[automation-sa-sre]

Automated approval: the AI review verdict for c2b0860 is APPROVE. See the "Cursor AI review" comment for details.