tri pr ready: a red check's name is not its reason -- compare why it fails (--why) #5852

tri pr ready calls a failure pre-existing when a check of the same name is red on recent master commits, on recent merged pull requests, or (since #5839) on the check's own workflow's newest master run. Names are compared, not reasons.

That leaves a hole the base PR's own NOW doc lists under "Not established": a pull request that adds a fifth conflicted type name to Corpus ratchet (expected-failure ledger), already red on master for four, reads exactly like one that adds nothing. The difference is in the failing step's output, under the same red name. The ::error:: annotations do not help: the ratchet prints the same four ##[error] lines whichever name moved.

Measured 2026-10-04: #5849's ratchet job 111329604306 and master 6e33229's job 111324093808 both fail at step "A type name may not gain a second definition". Both print ledger 77 name(s), observed 81 and the same four NEW conflict lines. That is a same-reason case; nothing told the reader so.

Wanted: tri pr ready N --why. For each failure called pre-existing, read both jobs' logs, take the failing step's name and its own output up to the first error annotation, mask what varies between runs (timestamps, durations, shas, long ids), and compare:

• the same step, and every line of this side's tail also printed there: SAME REASON;
• a different step, or a line here that is not there: NEW REASON, its own verdict, exit 7, and --merge refuses.

Off by default (it downloads two logs per pre-existing failure). Anything that cannot be read says "cannot compare" and changes no verdict.

Refs #5837 #5839