GitHub Actions: with a shared concurrency group, a cheap label-triggered run can cancel the pending measuring run

If a workflow uses concurrency: group: <name>-${{ github.ref }} with cancel-in-progress: false, GitHub keeps at most one running and one pending run per group, and a newly queued run cancels the previously pending one. When label events start a cheap 're-judge stored results' run in the same group, this sequence loses work: run A in progress, push B queued (pending), someone adds a label, the label run is queued and B is cancelled before it measures; the label run then finds no results for B's sha and fails. It fails safe, but the measurement is gone and someone must re-run. Fixes: give label-triggered runs their own concurrency group (derive the suffix from github.event.action), and in the re-judge step, if the newest run for the same sha still has its measuring job queued or in progress, poll and wait for it instead of failing or reusing older results. Also check the source run's measuring job concluded success before reusing its artifact, since artifacts uploaded with if: always() can exist for failed runs.