[katbyte]

After a release, rerun the failed binary scan jobs in place instead of starting a new scan.

Why: the rescan from #147 fired correctly after v1.3.4 and passed, but the commit stayed red. GitHub attached it as new check runs beside the original push failure, so main showed 1 failing and 21 successful. Only a rerun of the failed run replaces its check run, which is what I did by hand to clear it.

The release workflow reruns the scan. A last job with actions: write finds every binary scan run on main's head that failed and reruns its failed jobs. The rerun re-downloads the latest release, which is now the one just published. If nothing is red it does nothing.

+  rescan:
+    needs: goreleaser
+    permissions:
+      actions: write # rerun workflow jobs
+        run: |
+          head=$(gh api "repos/$GH_REPO/commits/main" --jq .sha)
+          runs=$(gh run list -w main-binary-scan.yaml -c "$head" ... select(.conclusion == "failure"))
+          for run in $runs; do gh run rerun "$run" --failed; done

The workflow_run trigger is removed along with its success gate and the zizmor suppression. The scan keeps push, schedule and manual dispatch.

-  workflow_run:  # zizmor: ignore[dangerous-triggers]
-    workflows: ['Release']
-    types: ['completed']
-  workflow_dispatch:
+  workflow_dispatch: # release.yaml reruns the failed jobs of the latest run on main once a release publishes

Things that are fine as they are. Every failed run on the head commit is rerun, not just the latest, so a red push run and a red Monday run on the same commit both clear. The actions: write permission is scoped to the one job; the rest of the release workflow is unchanged. Could not be exercised before merge since it only runs on a tag; yamllint, actionlint and zizmor pass on both files.