GeezerVison

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

On a manifest-less hosted project (the default v5 shape after a bare
`scan`), `remove <purl> --preserve-state` routes through
`remove_hosted_only`, which restored the pin to upstream but never said
so: the "no preservable local state" note existed only on the
manifest-backed hosted leg, and neither path put the
`hosted_state_not_preservable` code in the JSON envelope's `warnings[]`
(only `rollback --preserve-state` did).

Share the warning between rollback and remove
(`rollback::hosted_state_not_preservable_warning`), and have both remove
paths print the `Note:` line in human mode and carry the warning in
`--json`. CLI_CONTRACT.md now lists remove as a reporter of the code.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

pdm_dir_candidates only reads unix_default on non-macOS Unix, so a
macOS build warned about an unused variable, and clippy -D warnings
failed on macOS hosts. Widen the existing Windows-only
allow(unused_variables) to macOS as well.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

npm >= 8 rewrites the origin of a lock's `resolved` URL to the
configured registry when `replace-registry-host` is `always` or equals
the URL's hostname. Hosted pins rewritten that way are fetched from
`<registry>/patch/npm/...` and every `npm ci` / `npm install` fails
E404, yet the hosted scan / get exited 0 with a success summary and
no warning (and the "already on hosted patches" re-run stayed silent).
socket-patch never read the setting.

The npm config layer walk (`resolve_outer_allow_remote`) now also
resolves `replace-registry-host` from the env var and the user /
global / builtin config files; `effective_replace_registry_host` adds
the project `.npmrc` in npm's precedence order and
`replace_registry_host_rewrites` matches a pinned host the way
@npmcli/arborist does (`always`, or the exact hostname; `npmjs` =
registry.npmjs.org). Whenever a root npm lock carries a hosted pin, the
engine emits a new `redirect_npm_replace_registry_host` warning naming
the layer that sets it and the remedies (`replace-registry-host=npmjs`
in the project .npmrc, or vendored mode). The setting is never
rewritten and the exit status is unchanged.

CLI_CONTRACT.md, docs/ecosystems.md and the npm compatibility suite
table describe the new warning.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

#688)

scan_lock_matches returned LockScan::WorkspaceMember as soon as it met any
`packages` key outside node_modules/ whose name@version matched the patch,
before looking at the other entries. A project with a normal registry
install of [email protected] plus an unrelated `file:` directory dependency
(or workspace member) whose package.json says [email protected] therefore had
the whole package refused with vendor_workspace_member, although the
registry copies are fully rewritable (hosted mode already pins them).

The namesake local source is now skipped like link / inBundle /
non-registry entries, with a vendor_workspace_member_skipped warning naming
it, and the refusal fires only when no rewritable instance remains. The
same scan feeds sibling-lock wiring and vendor --check's wiring audit, so
that audit now also covers the registry copies of such a project instead
of skipping the lock entirely.

The takeover half of the issue (hosted pin restored before the refusal)
was already fixed by #963.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

npm >= 12.1's native `npm patch` records the project's own diff in the
root package.json `patchedDependencies`, adds a `patched: {integrity,
path}` record to the lock entry and writes lockfileVersion 4. Every
install extracts the locked tarball and then applies that diff, failing
EPATCHFAILED when it no longer applies. The hosted npm lock rewriter knew
none of this: it pinned the entry to the hosted tarball, kept the
`patched` record and reported a clean switch, so every later `npm ci` /
`npm install` failed (or, for a non-overlapping diff, installed bytes VEX
can never attest). The vendored backend refused the v4 lock but told the
user to upgrade with npm >= 7, which cannot help.

Hosted: `rewrite_npm_lock` now leaves a dep on its registry entries in
every present npm lock when the root manifest has a `patchedDependencies`
key for `name@version` (or the bare name), or any present lock's matching
`packages` entry carries a non-null `patched` record. It warns
`redirect_npm_patched_dependency_skipped` naming the key or entry and the
remedy, marks the uuid bundled-skipped so the in-run VEX never assumes it,
and records it in a new `refused_npm_uuids` set so the hosted engine never
confirms it from a sibling lock. Other packages in the lock are still
pinned. The entry-identity derivation is factored into
`npm_lock_entry_identity` and shared.

Vendored: the lockfileVersion 4 refusal (same code,
`vendor_lockfile_version_unsupported`) now names `npm patch` /
`patchedDependencies` and the real remedies instead of the npm >= 7
upgrade advice.

CLI_CONTRACT.md and docs/testing/npm-compatibility.md document the new
warning and the v4 refusal.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>