fix(dependabot): refuse a check rollup the token could not fully read

[twistedmelonman]

A fine-grained token cannot read check results, and GitHub does not say so

Fine-grained PATs have no Checks: read permission at all
(community#129512). The
API does not refuse the query for it. It returns statusCheckRollup with
HTTP 200 and the correct totalCount, then nulls every CheckRun the token
may not see.

Measured on kebab-tax-netlify#280, digest token vs a full login:

	contexts	readable
full login	12	12
digest token	12	1 (the Netlify StatusContext)

Mapped as written, that PR's 7 failing builds and 1 green required check
became "1 failing check, 0 required checks".

Why this was worse than a broken run

Reproduced against the classifier: a PR whose only checks are nulled CheckRuns
classified as ready-to-merge and was issued a paste-ready
merge-lock authorize line.

bucket=ready-to-merge blocking=0 advisory=0
merge-lock authorize #9 "ok"

Most of the fleet has no Netlify status to survive the nulling, so that was the
common path, not an edge case. A digest that recommends merging PRs with
failing builds is worse than no digest — it is precisely the failure the
classifier was written to prevent, arriving through the one door nobody was
watching.

Three layers, in depth order

• collect.sh refuses any response containing a nameless context, naming
  the count and the discussion. An unreadable check is not an absent one.
• classify.sh adds a checks-unreadable bucket that outranks every other
  signal — nothing else can be trusted once the check data is known partial.
  Second line of defence, in the component that decides what is safe to merge.
• render.sh renders that bucket first and says plainly that nothing in it
  is green.

Verified both directions against the live token: the digest token now exits 1
with a clear reason; a fully-scoped login still completes with rc=0.

Also

• GraphQL errors are grouped rather than printed once per context. One refused
  permission produced eleven identical lines; it now reads
  FORBIDDEN at …contexts.nodes.0 (and 10 more): ….
• The private-repo probe read repo metadata, which answers under Metadata
  alone — so it passed for a token that could not read a single commit. It now
  reads commits, matching what the survey needs.
• The error formatter now keeps GraphQL's path, which is what identified the
  failing field. The test that extracts it reads a multi-line jq program; a
  line-based grep found nothing after the reformat and failed for the wrong
  reason.

The regression test was validated against the unguarded classifier, where it
fails with "a PR whose checks are all null classified as ready-to-merge". It
first passed vacuously against an undefined path variable — that is now caught
explicitly.

What this does not resolve

The digest still cannot read check results for private repos under a
fine-grained token, and no permission grant fixes that. It now fails loudly
instead of lying. The options — a classic PAT, a GitHub App, or accepting
public-repo-only coverage — are a decision, not a bug, and are left for that
decision rather than pre-empted here.

Advances #120.

https://claude.ai/code/session_01ESsw699T54JHARkQXrdL3o

[claude]

Checks for blocking issues completed. No bugs, regressions, security vulnerabilities, missing error handling, or data loss risks identified.

The PR adds defensive measures to prevent silent failures when fine-grained GitHub tokens lack read access to check data. The multi-layered approach (collect.sh validation, classify.sh detection, render.sh warnings) correctly prevents unreadable checks from being treated as passing. Test coverage validates the regression prevention.

VERDICT: PASS