Classify action_required checks and RTD shallow-clone failures as non-actionable

[costajohnt]

Problem

PRs from forks can have CI checks that are not actionable by the contributor, but the CLI currently classifies them as actionable, causing the PR to show as "Needs Attention" when it should be "Waiting on Maintainer."

Two specific patterns observed on nteract/papermill#867:

1. GitHub Actions checks with action_required conclusion

Fork PRs often require maintainer approval before GitHub Actions workflows can run. These checks show conclusion: action_required in the GitHub API. The CLI currently doesn't surface these at all in failingCheckNames or classifiedChecks, but their presence means the PR is blocked on maintainer action — not contributor action.

Expected behavior: If all failing/pending checks are either action_required or already classified as fork_limitation, the PR status should be waiting_on_maintainer (not needs_addressing).

2. ReadTheDocs shallow-clone failures on fork PRs

RTD sometimes fails with fatal: reference is not a tree: <commit-hash> when it shallow-clones the upstream repo but the commit lives in the fork. This is an infrastructure issue, not a code problem.

Current classification: actionable
Expected classification: fork_limitation or a new infrastructure category

Context

The classifiedChecks system already handles some of these cases well — e.g., yoga#1903's Facebook Internal - Linter is correctly classified as fork_limitation. This issue is about extending that system to cover two additional non-actionable patterns.

Suggested approach

1. In collectActionableIssues() or the check classification logic, treat checks with conclusion === 'action_required' as a new category (e.g., maintainer_approval_required) that doesn't count toward needs_addressing
2. Optionally, add a heuristic for RTD failures on fork PRs — if the check name matches docs/readthedocs.org:* and the PR is from a fork, classify as fork_limitation