GeezerVison

`setup` previously only added its install hook. This adds two inverse modes,
both honoring the existing --dry-run / --yes / --json flags and printing the
exact set of proposed edits before touching disk:

- `setup --check`: read-only verification. Exits 0 only when every package.json
  is configured for socket-patch and none failed to parse; otherwise exit 1.
- `setup --remove`: reverts the lifecycle scripts setup added. Full revert —
  emptied postinstall/dependencies keys are deleted, an emptied `scripts`
  object is dropped, sibling scripts and key order are preserved.

Scope is npm-family only, matching the surface `setup` already configures;
check/remove operate purely on package.json.

Core: `remove_socket_patch_from_script` + `remove_package_json{_object,_content}`
in detect.rs (exact inverse of generate_updated_script, reusing the same
non-object guards) and `remove_package_json` in update.rs.

Tests: core unit tests; setup_invariants check/remove flows; cli_parse_setup
flag + conflict coverage; and the setup-matrix driver now does a non-destructive
check->remove->check round-trip after install/verify, asserted for npm-family
cases (untagged elsewhere, consistent with the non-blocking BASELINE GAP
convention).

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

…ences

The previous round-trip inspected package.json (grepped for socket-patch) and
flag state. Replace it with a behavioral verification driven by real
(setup)·(package-manager install) cycles, for npm-family cases that run setup:

  install        -> patch NOT applied   (no hook yet)
  setup --check  -> fails               (not configured)
  setup --yes; setup --check -> passes  (configured)
  reinstall      -> patch applied       (hook fires; the main actual_applied)
  setup --remove --yes; setup --check -> fails  (reverted)
  reinstall      -> patch NOT applied   (hook gone)

A clean `rm -rf node_modules` precedes each observation so the lifecycle hook
acts on a pristine package. run-case.sh factors out do_install/verify_applied/
reset_modules; emit_result drops `remove_clean` and adds applied_before_setup,
applied_after_remove, and check_before_setup_exit. The harness round_trip_failure
asserts the patch bookends are not-applied and check goes false->true->false.
Non-npm / no-setup cases keep the simple single-install flow unchanged.

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

…the file

The matrix decided "applied" by scanning the patched file for the marker
string. Now it actually EXECUTES the patched module with the ecosystem's
standard runner and checks for the marker in the runtime output:

  npm/yarn/pnpm -> node <file>     bun -> bun <file>     deno -> deno run
  pip -> ./venv/bin/python <file>  uv -> uv run python   poetry/pdm/hatch -> *run python

To make the patched code observable at runtime, the committed blob is now
runnable: `console.log("MARKER")` for JS, `print("MARKER")` for Python.
Compiled/loaded ecosystems we can't execute (cargo/go/maven/nuget/gem/
composer) keep an inert comment and fall back to reading the file (`cat`),
preserving today's behavior for those gaps.

verify_applied() runs every resolved copy of the file (covers hoisting, the
pnpm store, and workspace/monorepo member dirs) and ORs the results.

Also fixes a parallel-test race: the blob was written to a fixed /tmp/sm_blob,
so concurrent package-manager test fns clobbered each other's fixture
(afterHash mismatch -> apply no-op). Each case now uses its own mktemp file.

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