check-issue-links.py prints OK after reading no subjects at all

What is observed, and where

scripts/check-issue-links.py, run against this repository while two issues and one pull request were open (#2497, #2499, #2498), printed:

repo: argszero/emrg, 0 open issue(s), 0 open PR(s)

OK: every open issue has exactly one open PR declaring it, each declaration is named back in the issue, and every open PR declares an open issue (0 subject(s) read)

and exited 0.

Zero subjects is not a clean queue here: gh issue list -R argszero/emrg --limit 20 and gh pr list -R argszero/emrg --limit 20 reported those three subjects in the same session. The tool's own reading and the CLI's disagreed, and the tool reported the disagreement as a pass.

Why that is a defect

This tool is the reading a cycle trusts before it claims a link is complete — linked / one-way / unclaimed / duplicate / unlinked, each with a remedy. A verdict that says "0 subject(s) read" is indistinguishable, to a caller that only looks at the exit code, from "every link is complete", and it is printed with the same OK. The family's rule is that a queue which cannot be read is not a clean queue: that is exit 2, never a pass.

What was measured about the cause (not yet isolated)

load_queue asks the one endpoint that returns issues and pull requests together, through _paged_json(["api", query]). In one session, the same command answered differently depending on the child process that ran it:

gh resolves to /Users/argszero/.emrg/install/bin/gh (version 2.58.0) on this host. A child that answers [] with rc 0 is not a failing call, so _gh's loud-refusal path never fires, and an empty queue is indistinguishable from a real one.

What the fix must satisfy

• Zero subjects is never OK. Either the reading is unmeasurable (exit 2, the family's convention) or the verdict names what it measured and why the count is zero. A queue answering "no subjects" while the CLI answers three is a fault.
• The two readings are compared, not merely printed. The tool already has the count it read; a second cheap reading of the open-subject count turns a silent disagreement into a named fault with a remedy.
• The []-with-rc-0 shape is pinned by a test with a stubbed gh, so the empty answer is exercised without touching the network: the tool must not print OK for it.
• The verdict must not depend on the environment that produced it. The exit code has to keep distinguishing clean, fault, and could not measure.

Not claimed

The root cause of the [] answer is not established here — the table above is where the investigation stopped, and it may be an environment property of this host rather than something the tool controls. This issue is about what the tool does with a zero-subject reading, which is wrong whatever the cause turns out to be.