chore(deps): group the codeql-action pins so both halves move together

[napetrov]

5 of 5 in a split stack.

#	PR	scope	base
1	#9	a dead link in an imported body warns instead of failing — unblocks Validate	main
2	#12	scope the Pages token to the deploy job and pin its actions — unblocks Security	main
3	#10	retry a 429 in the link check instead of accepting it	#9
4	#11	run the pinned-upstream check even when the link check failed	#9
5	#13	group the codeql-action pins so both halves move together	#9

#9 and #12 are independent and both go straight to main — they fix the two unrelated jobs
that are red there, and neither waits on the other. #10, #11 and #13 sit on #9 only so their
Validate runs are green while main's link check is failing; GitHub retargets them to main
when #9 lands.

main is failing two independent jobs, so any PR fixing one still displays the other.
Nothing here introduces the failure it shows:

PR	red check	fixed by
#9, #10, #11, #13	zizmor — the Pages workflow from #7	#12
#12	validate — the dead docs.vllm.ai link	#9

Everything else is green on every PR. All five test-merge into main cleanly in any order,
and the merged combination passes the full gate plus zizmor and actionlint.

What this changes

Dependabot opened two pull requests this morning and neither can pass:

#5 (codeql-action/init)     Loaded a configuration file for version '4.37.9',
                            but running version '4.36.2'
#6 (codeql-action/analyze)  Loaded a configuration file for version '4.36.2',
                            but running version '4.37.9'

github/codeql-action/init and github/codeql-action/analyze are two entry points into one
action, and the bundle checks at runtime that both halves came from the same release.
Ungrouped, dependabot treats each path as its own dependency and opens a pull request per
path — so each one bumps half the pair and leaves the workflow internally inconsistent. The
failure is not a regression in either version, and not something either pull request can fix
on its own.

Grouping makes the pin move as the unit it already is. It is also the only dependency here
where that applies: everything else in .github/workflows is a standalone action whose
version is nobody else's business.

Needs a maintainer action

#5 and #6 have to be closed for the grouped pull request to replace them — dependabot
will not fold existing single-dependency pull requests into a new group. I have not touched
them.

Checklist

• I checked description against requests a user would really type — see CONTRIBUTING.md. (no skill text changed)
• python3 tools/validate_skills.py passes locally.
• Every commit is signed off with git commit -s (DCO).

[xaleryb]

Reviewed, rebased onto 2c8c60a (#9's commit was in this branch and has already landed as 49813a5, so it is dropped here), and extended by one commit.

The diagnosis holds, measured rather than taken on trust. Both halves' failures, from the two jobs:

#5  ##[error]Loaded a configuration file for version '4.37.9', but running version '4.36.2'
#6  ##[error]Loaded a configuration file for version '4.36.2', but running version '4.37.9'

And the dependency names dependabot actually uses, from its own commit trailers, are github/codeql-action/init and github/codeql-action/analyze — so github/codeql-action* matches both, and would also pick up a third entry point such as upload-sarif without another edit. main is currently consistent (8aad20d1 = v4.36.2 on both halves), which is why codeql.yml is correctly left alone.

What the extra commit fixes. applies-to defaults to version-updates, so the group as written left one path open: a security advisory on either half arrives as its own single-dependency pull request and splits the pin again — the same failure, reached a different way. The pattern is now stated twice, once per applies-to.

Checks. Nothing in CI validates this file — a malformed one surfaces only as a repository-level Dependabot error days later — so: YAML parses, and the result validates against the SchemaStore dependabot-2.0 schema.

One interaction worth recording. cooldown: default-days: 7 could in principle release one half of a group and hold the other, which would resurrect the split. It cannot here: both halves are the same repository at the same tag, so they share a release date (v4.37.9, 2026-08-26) and age identically.

Alternatives considered and rejected: grouping everything (patterns: ["*"]) couples unrelated bumps so one bad one blocks all; ignore on one half leaves the other permanently stale; a floating @v4 tag trips zizmor's unpinned-uses; CodeQL default setup cannot be SHA-pinned or reviewed. A shared SHA in an env var is not an option at all — uses: accepts no context expressions.

Follow-up, not for this pull request. #5 and #6 both propose the same SHA cdf488f5 (v4.37.9), so rather than closing them and hoping the grouped pull request re-proposes that version, the deterministic path is one small pull request bumping both halves to cdf488f5 in a single commit, after which #5 and #6 close as superseded. A one-line check that the two codeql-action SHAs are equal would also catch a hand-edit, and is worth its own issue.

[xaleryb]

Approved. Rebased onto 2c8c60a, extended by one commit closing the applies-to gap, and verified — details in the review comment above. GitHub's own .github/dependabot.yml check passes alongside the rest.

Per the discussion, #5 and #6 will be merged rather than closed, so Dependabot records 4.37.9 as applied rather than dismissed. Both propose the same SHA cdf488f5, and codeql.yml's concurrency group cancels a superseded run on main, so the intermediate split state need never report.