Respect required CI checks

[SeanMcTex]

Summary

This PR is based on #10 by @lukelabonte (Luke LaBonte), rebased cleanly onto main and extended with a few additional fixes. All four of Luke's commits are preserved with his authorship intact.

What Luke's work does

• Fetches required check metadata from GitHub's GraphQL API (isRequired, branchProtectionRule).
• Treats missing required contexts as pending, so a required check that hasn't reported yet doesn't show as green.
• Introduces a notStarted build status (gray play.slash icon) for PRs where required CI hasn't kicked off yet — previously these showed a misleading green checkmark.
• Keeps non-required checks out of the main merge-blocking status.
• Shows approval-gated non-blocking checks as a secondary summary row ("Non-blocking: 1 waiting for approval").
• Unifies the single-PR fetch path to use the same GraphQL query as the batch path, removing the GHPRViewResponse struct.
• Adds tests for required-check handling, missing required contexts, and the non-blocking summary.

What was added on top

• Replace name-based approval gate detection with GitHub's WAITING status. The original used name heuristics ("approve"/"approval" in check names) to identify approval gates. In GitHub Actions, CheckRun.status == WAITING is the authoritative signal — set exclusively when a job is blocked on environment protection approval. The heuristic functions (isApprovalGate, approvalGateName, parentWorkflowNameForApprovalGate) are removed; WAITING status drives all approval gate logic. Test fixtures updated to use WAITING CheckRuns instead of approval-named StatusContexts.
• Deterministic required context ordering. Array(Set(...)) now has .sorted() to give stable ordering across calls.
• Simpler ForEach in non-blocking summary. Replaced ForEach(Array(summary.segments.enumerated()), id: \.element.id) with ForEach(summary.segments) using Identifiable directly.

Test plan

• Build and run on a repo that uses required CI checks — PR status should reflect required checks only
• Open a PR where required CI hasn't started yet — should show gray play.slash, not green checkmark
• Verify non-blocking approval-gated checks appear in the secondary summary row
• Run test suite: xcodebuild -project MonitorLizard/MonitorLizard.xcodeproj -scheme MonitorLizard -destination 'platform=macOS' -configuration Debug CODE_SIGNING_ALLOWED=NO test

[lukelabonte]

I left two comments on the WAITING handling. I think using WAITING is the right direction, but I’m not sure we want to make it the only approval-gate signal or treat every WAITING check as approval-related.

[lukelabonte]

I think this now treats every WAITING check as approval-related work.

That might be right for GitHub Actions environment approvals, but the code doesn’t check that the waiting check is actually an approval gate. If GitHub or another provider returns a non-approval check in WAITING, we could show the PR as Not started even though CI is active.

Could we either scope this more tightly, or add a test that proves a non-approval WAITING check doesn’t get hidden?

[lukelabonte]

I think this drops the fallback for approval gates that come through as legacy StatusContext entries.

The old path handled contexts like ci/circleci: dead_code_cleanup/approve_dead_code_cleanup by treating them as waiting for approval. This now only works if we get a CheckRun with status: WAITING.

Are we sure external providers won’t still send approval gates as StatusContext + PENDING? If not, I think we should keep the WAITING path but leave the old name-based fallback for legacy contexts.