fleet-status: compute the lanes for fork PRs

[askalf]

Problem

fleet/verify and fleet/review are required checks, and a fork PR could never get either one. The status job skipped a fork head on every event, and the script refused a fork ("the fleet does not review it"). Redline now reviews fork PRs, so an outside contributor's PR that Redline approved and whose required CI passed stayed blocked with no way through.

Rule for a fork PR

• fleet/review: Redline's verdict at the current head. Approved is success, changes requested is failure, no verdict at the head is pending. It is not held for verification, because no seat verifies a fork.
• fleet/verify: the base branch's required checks passed at the head (the fleet/* contexts excluded, as for same-repo PRs). Where the branch requires no checks, it stays pending with "an outside contributor's PR: the operator verifies and merges". The verified label and verification comment never verify a fork.
• Docs-only and bot-PR exemptions and every same-repo rule are unchanged.

Which events run for a fork, and the safety invariant

• issue_comment and workflow_run run the default branch's workflow with a write token, so the job now runs on them for a fork head. A fork's workflow_run lists no pull requests, so the script finds the PR from the head repo and branch (checking the repo, since the head filter matches only the owner).
• A fork's pull_request and pull_request_review events run the PR merge ref's workflow with a read-only token, so they stay excluded. The new Fleet review relay workflow runs a no-op on pull_request_review; its completion fires the workflow_run path, so a Redline review on a fork refreshes the lanes. It has no token permissions and no actions or checkout.
• Invariant, stated in the workflow: no step checks out or executes PR head code. The only checkout is the default branch's script, and the script only calls the REST API.

Tests

The fleet-status test covers a fork approved at head with required CI green (both success), changes requested (review failure), no required checks (verify pending with the operator description), CLI runs against a stubbed GitHub (PR number and head-branch lookup), the job's if: evaluated per event (a fork's pull_request and pull_request_review do not run it; a fork's workflow_run and a PR comment do), and same-repo behavior unchanged. The new cases fail against the default branch's script and workflows. actionlint is clean.

[sprayberry-redline]

Approve.

The change lets a fork PR earn both fleet lanes without any step touching fork code: the status job runs for a fork only on issue_comment and on workflow_run completions (a fork's CI, or the new no-permission relay that turns a pull_request_review into a workflow_run), the script resolves the PR from HEAD_REPO/HEAD_BRANCH because a fork's workflow_run lists no pull requests, and laneStatuses treats a fork as verified only by required CI at the head while letting Redline's verdict stand ungated. I traced the if: against each event shape (fork pull_request and pull_request_review excluded, same-repo relay completion excluded so it does not double-run, fork CI and relay completions included) and the laneStatuses branches against the base version; the same-repo paths are unchanged and the new tests fail on the base (prsFromHead is not exported there and the fork verify description falls through to the Breaker text).

Minor, non-blocking: a workflow_run from a deleted fork carries head_repository: null, so null != github.repository runs the job with empty HEAD_REPO and PR, and the script exits 2. That is a failed run on the default branch only, attached to no PR, so it is noise rather than a wrong status; a github.event.workflow_run.head_repository != null term in the fork clause would silence it.