Stop push/pull_request CI runs from racing to cancel each other

[mkarlesky]

Summary

A push to a branch with an open PR fires both a push event and a pull_request:synchronize event for the same commit. Both previously shared one concurrency group (keyed only on branch name), so whichever run happened to start second cancelled the other — sometimes the pull_request-attached run, whose checks are what a reviewer actually sees on the PR.

• Keys the concurrency group on event name too, so push and pull_request runs for the same branch can never cancel each other; each event type still dedupes/cancels its own superseded runs as before.
• Adds a check-duplicate-push job that queries the GitHub API for an open PR on the pushed branch and, if one exists, skips every other job in the push-triggered run entirely — restoring single-run-per-commit behavior without relying on a cancellation race to get there.
• Every job's if: explicitly ANDs in success() alongside the new skip check, since a custom if: replaces GitHub's default implicit success-of-needs check rather than being combined with it.

Test plan

• YAML syntax validated (ruby -ryaml -e 'YAML.load_file(...)')
• Manually traced every job's needs:/if: wiring to confirm the original "only run if dependencies succeeded" behavior is preserved alongside the new skip guard
• Live validation in progress on this PR itself: after opening this PR, an additional commit will be pushed to this same branch to fire both a push and a pull_request:synchronize event for the same commit — the exact scenario this fix targets. Expected: the pull_request-triggered run (this PR's checks) runs to completion, unaffected; the redundant push-triggered run's check-duplicate-push job detects this open PR and skips its remaining jobs. Results will be added to this PR's checks/comments once observed.

🤖 Generated with Claude Code