fix: don't fail the check group on transient GitHub API errors

[dhedey]

Why are we doing this work?

During the GitHub incident on 17 Aug, check-group failed PRs whose required checks were all green — this run logged All required checks were successful! and then crashed, because the PATCH updating the PR comment came back 503 after octokit had exhausted its own retries. The action has a 40-minute budget to poll through exactly this kind of blip, and wasn't using it.

What does this PR change?

Makes the check-group action ride out GitHub API errors that say nothing about the PR:

• notifyProgress is now awaited — the unawaited call turned a rethrown error into an unhandled rejection that killed the process.
• Failing to write the PR comment now only warns; it's informational, and the check statuses it summarises are unaffected.
• Transient errors in the poll loop retry on the next interval instead of calling core.setFailed immediately.
• The timeout message names the last API error, so an outage doesn't masquerade as failing checks.
• The one-shot calls before the loop starts (listing PR files, reading checkgroup.yml) retry with backoff.
• Transient/403 classification duck-types on status rather than instanceof RequestError.

Why instanceof RequestError had to go

The existing 403 branch could never match. Several copies of @octokit/request-error are installed side by side, and the one that throws is not the one src/ imports:

$ node -e "..."
top-level version 2.1.0
nested version 3.0.1
same class? false
instanceof top-level? false name HttpError status 503

So every comment failure — including the expected 403 on fork PRs — took the throw e path.

Verification

There's no test harness in this repo, so I drove CheckGroup from a script with a stubbed octokit that reproduces the failure and its neighbours. Against the pre-fix dist, the 503-on-comment case crashes with an unhandled rejection and exits 1; after the change:

Scenario	Result
503 on the PR comment, checks green	warns, exits 0
403 on the PR comment	logs once, exits 0
503 on the check-run listing, then recovers	retries per interval, exits 0
503 on the PR file listing, then recovers	retries with backoff, exits 0
503 for the whole timeout window	fails, naming the API error
404 on the check-run listing	still fails fast, unchanged

yarn lint, yarn build and pre-commit run all pass. yarn format is deliberately not run — prettier is not clean on master and would rewrite every file.

Follow-up

Once this lands, gridai/grid's .github/workflows/probot-check-group.yml should be repinned from 08fa537 to the merge commit.