upstream-sync --check says CHECK ok when the compare read fails and both mains are the same commit #826

When the compare read fails and both main refs already point at the same commit, upstream-sync.mjs --check prints status: unknown and then exits 0 with CHECK ok. The one failure the check is supposed to catch — "I could not ask the repository how far apart the two mains are" — is the only one that passes.

Evidence (main bbd29584)

• .github/scripts/upstream-sync.mjs:77-84 leaves aheadBy / behindBy / status at 'unknown' and commits at null when /repos/<upstream>/compare/<upstream>...<fork> is not 200. No error is recorded.
• :113-128 builds problems from the ruleset read and from upstreamSha !== forkSha — the comparison read is not one of them.
• :130-133 therefore reaches CHECK ok whenever the ruleset is healthy and the SHAs are equal, even though the comparison never answered.

Reproduced with a fake fetchImpl (refs equal, /compare/... → 502, ruleset active / bypass_actors: []):

upstream main : aaaaaaaaaaaa…
fork main     : aaaaaaaaaaaa…
ahead_by: unknown  behind_by: unknown  status: unknown
ruleset 25173372: enforcement=active bypass_actors=[] current_user_can_bypass=never
CHECK ok — both mains are aaaaaaaaaaaa, ruleset 25173372 is active with no bypass actor
exit 0

This is the same class as the ruleset 404 fixed in #815 (:114-116 fails the run and names the id): an unreadable read is not an absent problem. It matters at exactly the wrong moment — the post-check that closes a release window runs right after the two mains became the same commit, so a 5xx or a rate-limit answer there is reported as a clean finish.

--commits already refuses this (:147-150 exits 2 with the comparison … could not be read); only --check has the hole.

Acceptance criteria

All three in .github/scripts/upstream-sync.test.mjs:

1. The hole fails. Fake fetch: both refs equal, /compare/... → 502, healthy ruleset. check() returns 1 and prints one CHECK FAILED — line that names the comparison read (id/endpoint and HTTP status). Both SHAs and status: unknown still print before it, like the unreadable-ruleset path.
2. The good path stays green. Same fake, /compare/... → 200 with status: 'identical', ahead_by: 0, behind_by: 0 → still exit 0, CHECK ok. This is the negative control against "fail whenever status is unknown".
3. --commits stays as it is. The existing "could not be read → exit 2" case keeps passing, and a new case shows the same fake failing --check while --commits also exits 2 (not 0 with an empty list).

Kill conditions — do not:

• replace 'unknown' with 0 for aheadBy / behindBy, or treat status: unknown as identical;
• skip the comparison when the two SHAs are equal (that is the case under test);
• add a retry or a timeout instead of failing the read (the runbook's rule is "stop and report", not "wait longer");
• change the compare URL, the request method, or the exit codes 0/1/2 contract documented in the header (:14-16).