check_silicon_coverage: a failed runner listing (403 body on stdout) counts as 1 online runner, so probe 2a never fires on the PR path #5213

What

scripts/check_silicon_coverage.sh counts a failed runner listing as one online runner. As a result, its zero-runner NO-GO (probe 2a) cannot fire whenever the job token cannot read runners, which is every PR and merge-queue run.

Mechanism (measured)

• On an HTTP error, gh api writes the error JSON body to stdout with no trailing newline.
• The runner loop appends stdout with >> "$RUNNERS", so both 403 bodies (Resource not accessible by integration, from the org listing and from the repo listing) end up on one non-empty line.
• n_runners counts non-empty lines, so it reads 1. The guard prints online runners visible (org + this repo): 1, and the -eq 0 NO-GO is skipped.
• The job token never has the scope to list runners, so this happens on every guard-tree run of the check. The guard tolerates the 403 (rc 0); only the count is wrong.

Effect on the verdict

The runner list feeds only two things:

• probe 2a, the zero-runner NO-GO;
• the label UNCOVERED vs MISSING on an axis that already fails either way.

The PASS/NO-GO on axes comes from job evidence, which the token reads in full. So today probe 2a passes vacuously on the PR and merge-queue path.

Why it is not in #5212

Counting honestly makes probe 2a fire on every PR, because the token cannot list runners. Which way to resolve that is a separate decision, made by a quorum round. #5212 (5xx retry) does not touch the runner loop.

Refs #5212