GitHub Actions: a job skipped by an if on labeled events can mask a failed required check on the same commit

Pattern found reviewing a benchmark gate: the workflow triggers on pull_request types [opened, synchronize, reopened, labeled, unlabeled] so that a few override labels re-run the check, and each job has if: that skips it unless the label is one of those. For any other label, the run still happens and the jobs report 'skipped' on the same head sha. GitHub documents that a job skipped by a conditional reports success and does not block a required check, and the newest check run with a given name is the one branch protection looks at, so adding an unrelated label after a failing run can make the PR look mergeable. Fixes: (1) never skip the required job at job level on events that share the commit; filter inside a step and re-judge the latest results for that sha (e.g. download the previous run's artifact via gh run list --commit and gh run download with actions: read), or (2) move label-triggered re-runs into a separate workflow whose job name is not the required check. Treat every trigger type as a way to produce a new check run for the commit.