feat(engine): PIN-DEAD — the one command a stranger runs

Reported by org-ops (census 08, R1) and re-measured here against the FORGE
rather than taken on their word: 3 install pins in the org, 1 dead.
`llm-ingestion-pipeline-security` pins ITSELF to `@v0.7.0`; that tag does not
exist, newest is v0.6.1. Anyone copying the single install command out of that
README gets a hard pip failure.

ERROR, not WARN: a dead documentation link costs a stranger a 404, a dead pin
costs them the install.

Not a duplicate of two checks it sits near. `LINK-DEAD` asks whether the repo
exists; `VERSION-TAG` reads the MANIFEST and asks whether that version was ever
tagged. All three land on guard today only because the same wrong number got
written in three places — a README pinning a bad ref in a repo with a correct
manifest is invisible to both.

Resolved against the forge, never the clone: a local tag can exist without
having been pushed, which portfolio-optimiser demonstrates directly. That uses
this session's decided acquisition model — `git ls-remote --tags` on the
register-derived https URL, anonymous, no API budget, and only for the repos a
README actually pins (nothing at all for the 19 that pin none).

A pin at a branch or a sha is a `byDesign` skip. `ls-remote --tags` cannot
answer it, and a loose pin is a different finding from a dead one.

The corpus sweep found a defect a unit test had not: offline, guard emitted the
SKIP *and* an OK reading "1 install pin(s) resolve against the forge" — a pass
asserted for a pin nothing had read. SKIP is never a pass. The OK now counts
only what was actually verified ("N of M"), and two tests pin it.

Measured before and after across all 21 clones: purely additive, no existing
finding moved. 19 repos emit PINS-NONE (OK — the check read the whole README
and found no subject), 2 emit real pins. Online, okf's 2 pins resolve and
guard's 1 does not: exactly one new ERROR org-wide, matching org-ops.

196 tests (was 187).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015AkHEqTSr1k3HbeiHu1ggW

CLAUDE.md

@@ -88,6 +88,16 @@ would recreate, in data, exactly the drift this plugin exists to remove.
   registered (measured). The substitute is one command from a clean clone, said
   plainly. A static badge asserting a run is the anti-pattern this gate flags —
   and an early draft of this README carried one.
+- **A dead pin is not a dead link, and it is not a wrong manifest.**
+  `PIN-DEAD` asks whether the ref a README install command pins actually
+  resolves — `LINK-DEAD` asks whether the repo exists, `VERSION-TAG` asks
+  whether the MANIFEST's version was tagged. All three coincided on guard only
+  because one wrong number was written in three places. It is an `ERROR`
+  because a dead documentation link costs a stranger a 404 while a dead pin
+  costs them the install. Resolved against the FORGE, never the clone: a local
+  tag can exist unpushed, which portfolio-optimiser demonstrates. A pin at a
+  branch or a sha is a `byDesign` skip — `ls-remote --tags` cannot answer it,
+  and looseness is a different finding from deadness.
 - **Three outcomes on references.** "No match" and "match on a known non-repo"
   must stay distinct findings. Collapsing them hides real loss inside correct
   text — the exact defect class this gate exists to catch.
@@ -197,11 +207,16 @@ would recreate, in data, exactly the drift this plugin exists to remove.
   gate that fails a correct repository is the mechanism that gets gates
   switched off, and this one fails almost all of them. The two repos that
   motivated it are both already answered: guard's manifest claims `0.7.0` with
-  no such tag, which is an existing `VERSION-TAG` `ERROR` (and the same root
-  cause as org-ops' `PIN-DEAD` — the README pins `@v0.7.0` too); okf's case
+  no such tag, which is an existing `VERSION-TAG` `ERROR`; okf's case
   turns on *behaviour-changing* commits past the tag, which no classifier reads
   off git. Two legitimate conventions coexist here — bump-at-release and
-  bump-first — and nothing in a clone says which one a repo follows. Recorded
+  bump-first — and nothing in a clone says which one a repo follows.
+  This says nothing about org-ops' `PIN-DEAD`, which is a different check on a
+  different subject: `VERSION-TAG` reads the MANIFEST and asks whether that
+  version was ever tagged, `PIN-DEAD` reads a README INSTALL COMMAND and asks
+  whether the ref it pins resolves. They coincide on guard only because the
+  same wrong number was written in both places; a README pinning a bad ref in a
+  repo with a correct manifest is invisible to `VERSION-TAG`. Recorded
   rather than deferred: a decision that is wrong is worse than no record, and
   the next session should not re-derive this measurement.
 - **No hook until the rule is precise.** A blocking gate that fails a correct
@@ -210,7 +225,7 @@ would recreate, in data, exactly the drift this plugin exists to remove.
 ## Commands
 
 ```bash
-npm test                                                  # 182 tests
+npm test                                                  # 196 tests
 node scripts/repo-standard-check.mjs --dir "$PWD"         # gate one repo
 node scripts/repo-standard-check.mjs --offline            # no network call
 node scripts/repo-standard-check.mjs --json               # machine output