fix: show queued trusted scans

[danbarr]

Summary

• replace workflow-level concurrency with a current-head coordination check
• repeatedly wait for the newest earlier trusted scan on the same PR before starting the current scan matrix
• preserve raw-scan artifact reuse, so version-autofix commits do not repeat the LLM scan
• skip reports from superseded PR heads
• document the trusted scan lifecycle, identities, fallback behavior, and troubleshooting

Context

On #927, the trusted scan for the Renovate commit was still running while the version-autofix workflow was queued by workflow-level concurrency. GitHub had not created any jobs for that queued current-head run, so the PR displayed only its completed fast checks and appeared ready even though security scanning was incomplete.

The coordination job starts on the current head after discovery and remains pending while any earlier run for the same PR is active. It rechecks the run list and waits on the newest earlier run, which serializes bursts of three or more heads. Once earlier runs complete, the current-head matrix starts and reuses matching content-addressed raw-scan artifacts. Unrelated PRs remain unaffected because the workflow keeps its existing skill-path filter.

Validation

• actionlint on all four skill workflow files, excluding existing ShellCheck diagnostics
• zizmor with no unsuppressed findings
• embedded github-script JavaScript syntax check
• documentation link target checks
• git diff --check

Because pull_request_target executes the default-branch workflow definition, the new coordination behavior must be confirmed with the next multi-commit skill bump after merge.

[samuv]

Thanks for addressing the missing current-head visibility. I found one race in the new coordination logic that still allows duplicate scan matrices after a burst of head updates. The rest of the workflow changes look good, and actionlint plus the current CI checks pass.

[samuv]

Thanks, the original A, B, and C coordination race is fixed, and the new operational documentation is useful. I found one rate-limit risk in the polling loop and one trust-boundary statement that should be made precise. The focused validation and all current CI checks pass.

[samuv]

Thanks for the follow-up. The coordination polling is now bounded, the trust-boundary language is precise, and the scan ordering fix remains sound. The latest CI and focused local checks pass.