bump-vendored-pinlisted

# Bump a vendored pin A pin is a claim: *this exact commit was reviewed and works here.* Moving it without re-earning the claim leaves every consumer running untested code that still looks pinned. The deliverable is the new SHA plus the evidence that earned it — a test count or a tree identity, cited in the commit. ## Procedure 1. **Resolve the new SHA from the upstream remote**, not from a local clone: `git ls-remote <url> <branch>`. A clone can be stale in either direction, and a stale one fails silently — it hands you a real SHA that is simply not the one you meant. 2. **Name what the move contains.** `ls-remote` resolved a name without downloading anything, so fetch the objects first, into the vendored checkout — the same one the next commands run from: ```bash git fetch <url> <branch> git log --oneline <old>..<new> ``` If that range errors *after a successful fetch* because the old SHA no longer exists, the upstream history was rewritten — go to step 3, because "what changed" has a different answer than the log. (Before a fetch, the same error means only that the objects are not local yet.) A surviving local copy of `<old>` can also let the range *succeed* against a rewritten upstream, so confirm ancestry rather than trusting the absence of an error: `git merge-base --is-ancestor <old> <new>` — a non-zero exit is the rewrite case, step 3. 3. **After an upstream rewrite, prove what survived**: `git rev-parse <ol