GeezerVison

Adds a non-blocking, data-driven test matrix that verifies the intended
`socket-patch setup` flow end to end for every supported
ecosystem/package manager:

  0. prepare a project with a dependency + a committed patch set
  1. run `socket-patch setup` to configure install hooks
  2. run the native install command for the package manager
  3. check whether the patch was applied (marker on disk)

plus negative controls (no setup, empty/wrong-target/alt patch sets).

The suite is ASPIRATIONAL and intentionally non-blocking: `setup` only
configures npm-family hooks today, so non-npm `baseline_with_setup`
cases are expected `known_gap`s — a baseline of what `setup` must
eventually support. Results are classified against a recorded baseline;
the runner exits non-zero only on a regression.

Components:
- tests/setup_matrix/matrix.json — declarative cases (targets x scenarios),
  the single source of truth for both the runner and the Rust wrappers.
- tests/setup_matrix/run-case.sh — self-contained bash flow driver
  (scaffold -> setup -> install -> verify -> JSON); generates the
  npx/pnpm shims inline so the hook resolves to the local binary instead
  of fetching the published wrapper.
- scripts/setup-matrix.sh — orchestrator (build/run/list/query/results),
  classifies pass/known_gap/progress/regression, emits machine-readable
  JSON.
- crates/socket-patch-cli/tests/setup_matrix_<eco>.rs (+ shared module),
  gated by a new `setup-e2e` feature; assert the aspirational ideal.
- tests/docker/Dockerfile.{npm,pypi} extended additively (pnpm/yarn via
  corepack; uv/poetry/pdm/hatch) — existing docker_e2e tests unaffected.
- ci.yml: a `setup-matrix` job, `continue-on-error: true` (must stay out
  of required checks).

No CLI/source behavior changes. Verified in Docker on all 9 images
(socket-patch 3.3.0): 80 cases, 56 pass / 24 known_gap, 0 regression /
0 error; npm/yarn/pnpm/bun apply, everything else is a documented gap;
all negative controls pass (no leaks).

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

Extends the setup-flow matrix with an `SM_LAYOUT` dimension modelling
real-world deployments beyond a single project:

- workspace (npm, pnpm, yarn, pip, uv): a root + several members,
  including a deeply-nested member and one with no dependency on the
  patched package. Exercises `setup`'s workspace handling — npm/yarn
  write the hook to every member, pnpm only to the root — and the
  cross-workspace apply on a single root install. npm/pnpm/yarn apply
  (the dependency hoists / lands in the pnpm store and is patched once);
  pip (nested requirements) and uv (uv workspace, one shared .venv) are
  Python gaps.
- monorepo: a polyglot repo with an npm workspace alongside
  python/rust/go/php/ruby/nuget/deno manifests. Confirms `setup` works in
  a mixed environment — it configures the npm hooks and does not choke on
  the foreign manifests; a root `npm install` then patches the npm slice.
  Runs in the npm image; the foreign manifests are present to test
  setup's robustness, not installed.

Wiring: `matrix.json` gains workspace_targets/scenarios and
monorepo_targets/scenarios; `run-case.sh` gains layout-aware scaffold /
install / multi-target verification; `scripts/setup-matrix.sh` threads a
`layout` column (+ `query --layout`); the Rust harness gains
`run_workspace_pm` / `run_monorepo`, with `*_workspace` tests on the
npm/pypi wrappers and a new `setup_matrix_monorepo.rs`.

Real-world finding (and fix in the harness): the install hook's `apply`
must run with the package manager's per-script cwd — root for the
project, the member dir for each member — so member postinstalls find no
manifest and no-op while the root applies. The driver therefore does NOT
pin SOCKET_CWD; pinning it to the root makes every member apply target
the root manifest and fail mid-install with "no packages found on disk",
breaking `npm install` in a workspace.

Verified in Docker (socket-patch 3.3.0): npm/pnpm/yarn workspace and the
monorepo apply (pass); pip/uv workspace are known_gap; single-project
cases unchanged. 92 cases total; 0 regressions.

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

Adds a `patch_missing` ablation (new `patchset: none` — no `.socket/`
fixture committed) to the single, workspace and monorepo scenario sets,
complementing the existing setup-not-run controls. Together they are the
controls that confirm `setup` is correct: each is identical to the
corresponding `*_with_setup` case except for the single removed factor
(the setup step, or the committed patch), and each must run UNPATCHED.

So every "it applies" case is now flanked by both ablations, e.g. for
single npm:
  baseline_with_setup  -> applied   (patch + setup)
  no_setup_control     -> unpatched (setup ablated)
  patch_missing        -> unpatched (patch ablated)

`run-case.sh` skips the fixture entirely for `patchset: none` (so the
hook's apply finds no manifest and no-ops — distinct from `empty`, where
the manifest exists but lists zero patches). No orchestrator/Rust changes
needed; the scenarios are data-driven and picked up automatically.

Matrix grows to 114 cases. Verified in Docker (3.3.0): all 22
patch_missing cases pass (run unpatched) — single 16/16, workspace 5/5,
monorepo 1/1; with_setup cases still apply; 0 regressions.

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