feat(pnpm): pnpm 7-12 vendor+hosted support — legacy grammars, zero-touch trustLockfile, takeover reconciliation, revert guards - #213

Conflicts:
- crates/socket-patch-cli/src/commands/vendor.rs: kept the branch's
  doc comment on the VexSummary warnings channel (code identical on
  both sides).
- crates/socket-patch-cli/tests/in_process_vendor.rs: both sides
  appended tests at the same point — kept BOTH the branch's
  hosted_to_vendor_conversion module (#213) and main's section-12
  drift-skip revert tests (#205).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Conflicts (crates/socket-patch-core/src/vendor/lock_inventory.rs):

Main's #201 rewired inventory_npm_lock to
Result<Option<...>, UnsupportedNpmLayout>, propagating the PnP-loader
refusals (vendor_yarn_berry_unsupported, vendor_pnpm_pnp_unsupported) as a
layout diagnosis instead of the calm None. This branch's #203/#213 work
added lockfile fallbacks on the pnpm refusal codes, including reading the
root lock under pnpm's node-linker=pnp.

Resolution: main's semantics win for BOTH PnP codes — under a PnP loader
the installed-tree crawl is structurally empty, so the honest scan outcome
is the propagated diagnosis, not a lock-only inventory posing as a served
project. The branch's fallbacks survive for the non-PnP refusals:
vendor_lockfile_version_unsupported (live-sibling check, else direct root
pnpm-lock.yaml read) and vendor_lockfile_missing (pnpm <=2 shrinkwrap.yaml).

Test reconciliation:
- pnpm_pnp_layout_still_inventories_root_lock →
  pnpm_pnp_layout_propagates_the_diagnosis (asserts the Err).
- stale_pnpm_lock/stale_shrinkwrap behind a yarn-berry PnP marker now
  assert the propagated yarn diagnosis instead of None (same protective
  intent, new channel).
- unsupported_flavors_yield_none's v6 comment updated: post-#213 the probe
  passes 6.0; the None comes from the dep-less lock.
- Branch tests mechanically adapted to the Result signature.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

#203)

* fix(scan): parse pnpm v5.4/v6 lock grammars in the lockfile supplement

Fresh-clone scan of a pnpm 7 or pnpm 8 project discovered ZERO packages:
inventory_pnpm_lock_at parsed only the v9 `name@version` key grammar, so
v6 keys (`/name@1.2.8:`) produced a leading-slash name dropped fail-closed
by is_safe_npm_name, and v5.4 keys (`/name/1.2.8:`) were skipped outright.
Confirmed against real pnpm-7/8-emitted locks (2026-08-18 matrix).

- split_pnpm_key handles all three grammars: peer-paren suffix trimmed,
  one leading slash stripped and remembered as legacy; legacy keys may use
  the v5 name/version form (segment after the last '/', truncated at the
  first '_' peer/hash suffix, digit-leading, no '@') — correctly parsing
  v5 peered keys like /styled-components/5.3.3_react@17.0.2; scoped v5
  keys parse via the same rule.
- The probe-failure fallback that reads a root pnpm-lock.yaml is narrowed
  to pnpm-specific refusals (vendor_lockfile_version_unsupported,
  vendor_pnpm_pnp_unsupported): a stale pnpm-lock.yaml left behind by a
  pnpm->yarn/bun migration is no longer resurrected as the live dependency
  set.

Tests: grammar cases quoted verbatim from real captured 5.4/6.0 locks,
plus migration regressions (stale lock behind .pnp.cjs / bun lock is not
inventoried; legacy lock alone still is).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* feat(pnpm): pnpm 7-12 vendor+hosted support — legacy grammars, zero-touch trustLockfile, takeover reconciliation, revert guards (#213)

* feat(pnpm): full pnpm 7-12 vendor+hosted support — legacy lock grammars, zero-touch trustLockfile, takeover reconciliation, revert guards

Built and verified against real corepack-pinned pnpm 7.33.5 / 8.15.9 /
9.15.9 / 10.34.5 / 11.22.0 / 12.0.0-rc.7 (plus legacy 1-6 probes) in the
2026-08-18 e2e campaign.

HOSTED, pnpm 7/8: the v5.4/v6.0 refusal is replaced by a real rewrite —
every instance key of a dep is spliced (v5 /name/ver and _peer-suffixed,
v6 (peer)-parenthesized; each owns its resolution), one ledger edit per
instance; a post-splice residual detector refuses the dep set-wide if any
instance shape the splice regex cannot claim remains (no partial
rewrites). Frozen installs from empty stores land patched bytes on both
majors; tamper fails ERR_PNPM_TARBALL_INTEGRITY.

HOSTED, pnpm 11/12 zero-touch: rewriting a v9 root lock now auto-writes
trustLockfile: true into pnpm-workspace.yaml (create with scaffold or
byte-preserving append; ledger-recorded as redirect_pnpm_workspace_trust;
--no-trust-lockfile-config opt-out; only ErrorKind::NotFound creates —
an unreadable existing file falls back to guidance, never overwrite;
re-scans heal a missing config on already-redirected locks). pnpm 11.22
and 12-rc frozen installs succeed with no flags and no CI changes; 9/10
ignore the key (verified); the sha512 pin still fails closed under trust.
Warnings name the actual spliced host (userinfo stripped) and both
per-major error codes, and pre-empt pnpm 12's own rebuild-the-lock advice
that silently unpatches.

VENDOR, pnpm 7/8: new pnpm-legacy backend (flavor-stamped so older
binaries fail closed) — package.json pnpm.overrides + legacy lock surgery
emitting exactly what those majors serialize (byte-stable under pnpm's
own re-lock). pnpm <= 8 absolutizes file: specifiers, so frozen installs
are path-bound: surfaced as vendor_pnpm_legacy_absolute_specifier, with
plain `pnpm install --offline` as the moved-checkout path (marker bytes
verified). Windows-shaped canonical paths are normalized (verbatim prefix
stripped, forward slashes).

CONVERSIONS + SAFETY: vendoring over a hosted-redirected npm-family purl
now reconciles the redirect ledger (artifact-uuid-anchored matching —
version-exact, v5 underscore keys claimed; degraded ledgers keep edits
fail-closed), firing vendor_supersedes_redirect exactly once; vendor
--revert byte-restores the hosted lock from the wiring originals. All six
npm-family vendor backends refuse to delete an artifact the live lock
still references when a repair-reconstructed entry has no wiring
(vendor_wiring_unknown_revert_blocked — the revert-brick fix); repair
stamps detected flavors and preserves corrupt artifacts when no rebuild
source exists. Legacy-era diagnostics: shrinkwrap.yaml projects get
pnpm-flavored no-lockfile guidance and join the lockfile-only supplement;
vendored lock entries get redirect_pnpm_entry_vendored instead of
entry-not-found.

Tests: e2e_redirect_pnpm_build.rs (new hosted capstone: pnpm 7-11 real
corepack legs incl. the zero-touch pnpm 11 proof, tamper negative,
hermetic v5/v6 legs), e2e_vendor_pnpm_build.rs ladder (@9/@10/@11 + real
pnpm 7/8 lifecycle legs), takeover/reconciliation/guard/heal unit + e2e
suites — all RED-verified where behavior changed. CLI_CONTRACT.md and
docs/ecosystems.md updated.

Stacked on #203 (lock-inventory legacy grammars); trivially overlapping
test hunks with #204/#208 carry identical content.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(pnpm-legacy): moved-checkout recovery needs --no-frozen-lockfile (pnpm defaults frozen on under CI)

CI caught what local runs could not: pnpm turns --frozen-lockfile ON when
CI=true, and the pnpm <= 8 moved-checkout recovery works precisely by
re-resolving the path-bound absolute specifier — frozen semantics skip
that re-resolution (pnpm 8: ERR_PNPM_OUTDATED_LOCKFILE; pnpm 7:
stale-path install). The lifecycle legs' recovery step now passes
--no-frozen-lockfile explicitly, and the vendor_pnpm_legacy_absolute_
specifier remedy (warning text, module doc, CLI_CONTRACT.md,
docs/ecosystems.md) recommends `pnpm install --offline
--no-frozen-lockfile` so real CI users get working advice.

Verified: the full capstone (10 legs incl. real pnpm 7/8 lifecycles)
passes under CI=true locally.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* test(pnpm-legacy): lock oracle uses the real path normalizer (Windows byte-exactness)

Windows CI proved the production normalizer right and the test oracle
wrong: the hermetic splice legs built their expected absolute specifier
with raw canonicalize().display() — the \\?\C:\ verbatim form the
normalizer exists to strip. normalize_canonical_root is now pub and the
oracle consumes it at both assertion sites, so the expected string is
built by the same transformation the backend writes and cannot drift.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* test(pnpm-legacy): in-file oracles also use the shared root normalizer

Windows CI surfaced the same oracle-drift bug in the module's own unit
tests: the fixture helper handed raw canonicalize().display() (verbatim
\\?\C:\ form) to the ROOT_TOKEN substitution, the no-leak contains probe,
and the moved-checkout fixture builder. All three now go through a
canon_root_str() helper built on normalize_canonical_root, so every
oracle spells the root exactly as the splice writes it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>