fix(ci): run the pinned-upstream check even when the link check failed

[napetrov]

4 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

Imported skills match their pinned upstream is the step after Link check and has no
if: always(), so it has never run on a commit where a link was dead. main has been
red on the link check since this morning, and for that entire window the answer to "does
what this repository publishes still match what was reviewed?" was not yes — it was
unknown, because nothing asked.

The two checks are independent. One reads URLs inside skill bodies. The other re-fetches
each pinned commit and byte-compares the vendored copy against it — and it is the more
serious of the pair, because a mismatch means either the copy was edited here or upstream
moved the commit under the pin, and both mean this repository is publishing something
nobody reviewed. Letting the first decide whether the second runs puts that answer in the
hands of whoever last reorganised a documentation site.

It does run now, and it passes — every import matches its pin:

OK   skills/vllm-xpu-run/ 6 file(s)
OK   skills/xpu-system-setup/ 4 file(s)
...

Step ordering is left alone. Link check first is the cheaper and more commonly
interesting failure, and with if: always() the order no longer decides what gets
reported.

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).