fix(ci): confirm deny-list negatives too, and fix a cwd-relative shallow probe

[hyperpolymath]

Follow-up to #522, which merged before this landed. #522 is live on main now, so these two defects are live on ~300 consumers.

Both were found by adding a test for the path production actually takes. Cases 1–12 of the fixture suite run against a complete git init repo; CI runs against a partial clone (--filter=tree:0). Nothing tested the code that protects production, and it had two bugs.

1. The deny-list's negative still trusted local merge-base on a partial clone

A treeless clone resolves every commit, so the API fallback was gated on "commits do not resolve" — making it dead code in CI. Trace awesome-haskell (pin 5a93d9d5, which predates the Hypatia fix and must be denied):

pin_is_known_bad -> local branch taken -> wrong negative -> continue -> NOT denied
classify_pin     -> same mis-fire -> API says ahead=90 -> OUT_OF_WINDOW -> notice
                 -> PASS, while running the frozen scanner

That is the exact false green the deny-list exists to prevent, on the very cohort that proved merge-base is unreliable there.

Fix: a local positive is still trusted (no false positives observed, and a deny must not require the network), but a local negative is accepted only from a complete clone — otherwise it is confirmed server-side.

2. clone_is_complete used a cwd-relative git-dir

rev-parse --git-dir returns .git, and the check was [ -e "$gd/shallow" ] — which resolves against the CWD, i.e. the consumer's checkout, which actions/checkout makes shallow by default. So .git/shallow would nearly always exist and every standards clone would be classified incomplete, permanently masking the complete-clone fast path.

Now uses --absolute-git-dir. Test 13c failed for exactly this reason, which is how it was found.

3. governance-reusable.yml passes GITHUB_TOKEN to the staleness step

The server-side confirmation is unauthenticated — 60/hr per runner IP — and exhausting it degrades the gate to ::warning. That fail-open is deliberate and loud (two warnings naming the pin; never a silent pass), and the common path never calls the API at all, since a genuine deny is a local positive. A token removes the cliff.

This reaches a consumer only once it re-pins past this commit — the script is read from standards HEAD, but the job definition comes from the pinned SHA — so it lands naturally with the propagation the deny-listed pins need anyway.

Tests: 16 → 19, still hermetic

The API is pointed at a closed port (http://127.0.0.1:1), so these are fast and offline:

PASS: partial clone: local positive still denies without the network
PASS: partial clone: unverifiable deny-list check is reported SKIPPED, not passed
PASS: complete clone: local negative is trusted silently (no SKIPPED warning)

run_case_out gained a leading-! inversion so a test can assert the gate did not say something. Suite verified from two different working directories, since defect (2) was cwd-dependent. 19/19 pass on top of current main; shellcheck -S warning clean.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud