feat: integrate exact multiversion graphs into normal install and lockfile v2 #330

Context

zed-pkg/zed-cli#315 implements and certifies finite exact resolved-graph materialization, including the canonical version-skewed cycle:

A@1 -> B@1 -> A@2 -> B@0 -> A@2

It stores each exact package-version/digest payload once and represents dependency edges as local symlinks, so the closing B@0 -> A@2 edge reuses the original A2 node instead of recursively copying a dependency tree.

The ordinary .zpkg.toml / .zpkg.lock v1 resolver still selects one version per org/name. This issue tracks the separate normal-install and lock-contract migration; it must reuse the exact graph and materializer rather than introduce another cycle algorithm.

Linear: DEN-3488
Product foundation: #315
Independent acceptance:

• test(DEN-3488): certify current circular graph product head zed-pkg-test/version-solver-e2e#4
• test(DEN-3488): black-box exact-version circular dependency materialization zed-pkg-test/zed-pkg-e2e#179

Required design

• Add a versioned lock contract keyed by immutable exact identity: registry, organization, package, exact version, and artifact digest.
• Permit multiple exact nodes with the same org/name but different versions in one solved graph.
• Preserve edge-local requirements and provenance; do not collapse the graph into one global selected version per coordinate.
• Keep lockfile-v1 reading backward compatible, but fail explicitly when a multiversion graph cannot be represented; never silently flatten or rewrite it.
• Make normal install, recursive prefetch, and frozen replay consume one exact solved graph.
• Reuse the feat(DEN-3488): materialize finite exact-version circular dependency graphs #315 content-addressed canonical node store and dependency-local symlink edges.
• Detect exact-node back-edges deterministically and emit the same terminal-visible and structured ores-otel diagnostics.
• Preserve bounded node/edge/path/depth limits and transactional project mutation.

Acceptance criteria

1. Resolve the canonical fixture from ordinary package manifests, not only a pre-resolved graph document.
2. Materialize exactly four canonical payload nodes and four dependency links; B@0 -> A@2 must resolve to the original A2 node.
3. Confirm there are no recursive payload copies or unbounded directory trees.
4. A repeated package name at different versions is not classified as a cycle unless the exact node identity is revisited.
5. Cover self-cycle, two-node cycle, shared completed node, diamond, version skew, and genuinely unsatisfiable multiversion graphs.
6. Produce deterministic graph bytes, lock bytes, cycle witnesses, and diagnostics across dependency declaration order and Linux/macOS/Windows.
7. Verify normal install, recursive prefetch, and frozen replay cannot diverge.
8. Verify lockfile-v1 compatibility and explicit migration/error behavior.
9. Mirror black-box acceptance into zed-pkg-test, pinning the exact product head.
10. Keep ores-otel terminal and structured fields free of credentials and local source paths.

A dedicated Linear child issue could not be created because the workspace has reached its free issue quota; the same acceptance contract is recorded on DEN-3488.