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]

Approved at 5bfdecd.

The change lets fleet-status.mjs compute both lanes for a fork PR instead of refusing it: fleet/verify becomes the base branch's required checks at the head (never the label and comment, per !fork in laneStatuses), and fleet/review is the reviewer verdict at the head without the verification hold. The job's if: admits a fork head only on issue_comment and workflow_run, which run the default branch's workflow with a write token, and the relay workflow turns a fork review into a workflow_run while carrying permissions: {} and no uses: or checkout. The fork branch name and repo reach the script as environment variables, not interpolated into the run: line, and the branch is encodeURIComponent-ed into the head=owner:branch query with the repository re-checked in prsFromHead since that filter matches only the owner. A deleted fork (head.repo null) still classifies as a fork.

The tests cover the cases that matter: fork approved at head with CI green, changes requested while CI runs, no required checks with the operator description, label plus comment not verifying a fork, the CLI's head-branch lookup rejecting a same-named branch in another of the owner's repos, and the job's if: evaluated per event against the workflow file, including that the relay's completion on a same-repo PR does not re-run the job. Each of those fails on the base script or workflow.