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.

[cloudflare-workers-and-pages]

Deploying amnesia-site with    Cloudflare Pages

Latest commit:	225aeeb
Status:	✅  Deploy successful!
Preview URL:	https://339ed364.amnesia-site.pages.dev
Branch Preview URL:	https://fleet-fork-prs-computed.amnesia-site.pages.dev

View logs

[sprayberry-redline]

Approve at 225aeeb.

The change lets a fork PR earn both required lane statuses without any seat verifying it: fleet/verify becomes the base branch's required checks passing at the head, and fleet/review becomes the verdict at the head with no verification hold. I traced the new if: in .github/workflows/fleet-status.yml for each event shape and it admits a fork only on issue_comment and on workflow_run of a listed workflow whose head_repository is not this repository, which are the two paths that run the default branch's script with a write token; a fork's own pull_request and pull_request_review runs still fall through every branch. The fork workflow_run path hands the script HEAD_REPO and HEAD_BRANCH through env, not inline in run:, and the script only puts the branch through encodeURIComponent into the head=owner:branch query, so an attacker-named branch has nowhere to land. prsFromHead correctly re-checks head.repo.full_name since the head filter matches the owner alone, and the CLI test at scripts/fleet-status.test.mjs pins that with a same-named branch in another of the owner's repos. In laneStatuses, verified still becomes true from requiredCi === 'passed' for a fork, and the !fork guard only removes the label-plus-comment route, which the test with labels: ['verified'] and a matching verification comment covers.

Minor, not blocking: a workflow_run whose head_repository is null (a deleted fork) passes the != github.repository branch and the script then exits 2 for want of a PR number; that run attaches to the default branch, not a PR, so nothing is blocked by it.