Show the favicon as passing when peer review is the only failing check

[roryabraham]

Fixed Issues

For https://github.com/Expensify/Expensify/issues/668743

Problem

#368 fixed the per-commit indicators in a PR's history, but the tab's favicon has the same problem. GitHub shows a red X in the favicon while a PR's checks are failing, and since the org-wide ruleset started triggering verifyPeerReview.yml, that X is there from the moment the PR opens until someone reviews it

Solution

Point the favicon link at the passing icon GitHub already serves when the only check holding the PR back is one we ignore.

That last part matters. GitHub keeps a favicon per state (favicon-failure, favicon-success, favicon-pending, in both .svg and .png) and swaps its own link.js-site-favicon between them — the SVG link even carries data-base-href for exactly that. So this is a one-attribute change to a URL GitHub is already serving.

• src/js/lib/checkStatusVerdicts.js (new) — the verdict cache and the classification logic, moved out of commitCheckStatuses.js. The favicon and the commit rows now share one cache and, more to the point, one decision about what counts as failing. Duplicating that would mean two places to get a wrong green wrong.
• src/js/lib/prFavicon.js (new) — resolves the PR's head commit, asks for its verdict, and swaps the link. Stores the href GitHub had set so it can be put back exactly rather than rebuilt.
• src/js/lib/api.js — getPullRequestHeadRefOid(), since the favicon reports on the PR as a whole, which is the state of its head commit.

Carried over from #368: a null verdict leaves whatever GitHub set alone, a verdict of false puts our change back, and the head SHA is re-read after 60s so a push doesn't leave us reporting on the wrong commit. Navigating off the PR drops our marker rather than holding a stale icon over whatever GitHub sets next.

One bug fix worth calling out: the first version ran a pass at init before the token had loaded out of Onyx. getOctokit() memoises for the life of the page, so that single early call cached an unauthenticated client and made every subsequent GraphQL request 403. The init path now touches nothing until the token is there.

Tests

GitHub only swaps in its status favicon for a signed-in session, so these set the failing favicon GitHub would have set and check what the extension does with it. Everything else — the verdict, the head commit lookup, the API — is real.

1. Run npm run build, then load the dist/ folder as an unpacked extension.
2. Open prevent live-tail cleanup from clearing RHP route params App#98020, whose head commit fails Check independent approval and nothing else.
3. Confirm the tab's favicon shows a green check once the checks have reported.
4. Open Guard FlashList ViewHolderCollection render against stale layout index (web crash) App#98015, whose head commit fails checklist as well.
5. Confirm the tab's favicon still shows a red X.
6. Navigate from the PR in step 2 to any non-PR page and confirm the favicon is whatever GitHub sets, not a leftover green check.

[NicolasBonet]

@roryabraham we need to fix conflicts

[roryabraham]

@NicolasBonet conflicts resolved

[os-botify]

🚀 Released in version 1.5.53 🚀