ci: batch Fleet status runs that a finishing workflow fires

[askalf]

Summary

fleet-status.yml runs once for each workflow that finishes (workflow_run), plus once for each PR, review and comment event. On 2026-10-06, status jobs were 44.5% of all jobs on the repos' exec runners. In truecopy, 47 of the day's 56 Fleet status runs came from workflow_run. Every one of those is a full ephemeral runner cycle for a 13-second API call, and for a given PR only the last one to finish matters, because the script re-reads everything and corrects what differs.

This adds a concurrency group that covers workflow_run runs only:

• workflow_run runs share a group per PR branch and triggering event, and a newer one cancels an older. Their check runs sit on the default branch, not on the PR, so a cancelled one marks nothing on the PR. Including the triggering event means a finished push run never cancels a pull request's.
• pull_request and pull_request_review runs each get a group of their own and are never cancelled. Their check runs are on the PR, where a cancelled run rolls up as a failed check, which is why this workflow had no concurrency group at all.
• issue_comment runs also get a group of their own and are never cancelled. They run on the default branch, so their check runs are not on the PR either. Leaving them out of the batching is a choice: this change only targets the workflow_run volume.

The group is keyed on the branch, not the head sha, so the existing check that nothing here reads the PR head ref or sha still holds.

Tests

fleet-status test: 218 pass, 0 fail. It checks the group expression, and that only a workflow_run run cancels an older one.

[sprayberry-redline]

Verdict: request changes. The concurrency expression separates finishing workflows by event, repository and branch, and the tests cover the expression and cancellation condition. The new comment incorrectly describes where issue-comment runs attach their checks.

1. Blocking: .github/workflows/fleet-status.yml:10

a cancelled one marks nothing on the PR. Every other event's check run is on the PR, where a

cancelled run rolls up as a failed check, so each of those runs alone and is never cancelled.

This includes issue_comment, but that event runs against the default branch, not the PR head or merge ref. Consequently, the claim that every remaining event attaches a check to the PR, and the cancellation rationale based on that claim, is incorrect. The PR description repeats the same claim.

Suggested fix:

Distinguish pull_request and pull_request_review from issue_comment in the comment and PR description. Describe keeping comment runs independent as a policy without claiming their checks attach to the PR.

rule:reads-as-generated

[sprayberry-redline]

Verdict: approve. The concurrency key separates workflow completion runs by source repository, branch and triggering event, while other events retain unique groups. The added tests pin that grouping expression and verify that cancellation is enabled only for workflow completion runs.