ci: check the csp override wherever its fixes live

[jonathanKingston]

#4's check assumes every group in the series is .patch files under
servo-patches/, and hard-fails on an empty glob. #2 moves the
content-security-policy fixes to commits on a fork and deletes csp-0001
accordingly, so merging it as-is turns the check red on main:

servo: 24/24 applied

no patches matched csp-*.patch

Confirmed by merging the two branches locally. This adapts the check so the
two PRs are independent — it is green both before and after #2 lands, so
neither has to wait for the other.

What it checks now

Whichever arrangement the README documents, rather than special-casing the
crate:

• A git + rev override means the fixes are commits on a fork and there
  is nothing to apply. What can rot there is the pin, so verify the rev still
  fetches and that the crate version at it matches what Cargo.lock resolves.
  That is exactly the condition cargo requires to accept a [patch] entry, and
  exactly what breaks when the crate publishes a new version and the fork is
  left behind — silent in the manifest, loud at build time.
• Anything else keeps the old behaviour: apply csp-*.patch to the
  revision behind the published crate.

The fork branch is rebased whenever upstream master moves — which is why the
override pins a rev — so it is deliberately not checked against upstream's
current tip.

Two things that fell out of writing it

The discriminator cannot be "is there an override line". main already has
one, and it names a path — meaning the reader applied the patch files
locally. It has to be whether the line names a git rev. My first attempt got
this wrong and the check caught it.

A git source with no rev now fails outright. That pins a branch, the fork
branch is rebased, so what a CSP source-expression matcher does would change
under cargo update. That is the reasoning #2 gives for pinning a rev —
enforced rather than only written down.

Verification

scenario	result
main as it stands (path override, csp patch file)	green — csp: 1/1 applied at 05528760
merged with #2 (fork pin, no patch files)	green — pinned to fb5fd0f1 … (crate 0.8.2)
lockfile doctored to resolve csp 0.9.0	red — this pin no longer satisfies it
override rewritten to a branch pin, no rev	red — A branch pin changes meaning whenever the fork is rebased

The failure hint now covers both arrangements; previously it only described
regenerating .patch files, which is the wrong instruction for a stale pin.

🤖 Generated with Claude Code