chore(skills): catch and fix vendored drift instead of waiting to notice it

[owjs3901]

Why

Two directions of drift exist and only one was covered.

cargo test holds the manifest to the documents in this tree — a hand-edited vendored copy fails every_origin_is_well_formed on its digest. Nothing checked whether those documents still match the repository they were copied from.

That second drift is caused by another project publishing, so it arrives with no commit here and no pull request notices it. And the copies are exactly what devup_skills install writes on a machine with no network — the machine this whole feature exists for.

It was already real

The moment the check was written it found this:

~ devup-ui: b0d61a2d5e21 -> 3b1c3bfff4be (16629 -> 20632 bytes)

devup-ui's SKILL.md had moved — that is #665, which added the rule that no .css file belongs in application source and the rule for what devup-ui extracts statically. A bare machine installing from this binary would have been told neither of them. This PR re-vendors it.

What the job does

Weekly (cron: 0 6 * * 1) and on demand:

1. node scripts/refresh-skills.mjs — re-vendor
2. Nothing moved → exit quietly
3. Something moved → write a Patch changepack, commit, force-push a bot-owned branch, open a PR (or update the open one)

Three decisions worth calling out

It opens a PR rather than only going red. A red scheduled run is a notification nobody acts on. A PR is the same information in a reviewable form, and it carries the refreshed bytes so nobody reproduces them by hand.

It writes the changepack itself. A re-vendored document changes what devup_skills install writes, so it is a shipped behaviour change. Without the changepack the refresh would fail the changepack required gate it has to pass, and sit unreleased.

It is deliberately not a pull request gate. Failing unrelated PRs over someone else's publish is exactly the trade devup-ui made by pinning a dependency to latest beside a committed generated file — every PR against its main went red for a staleness none of them caused. This blocks nobody.

The branch is force-pushed on each run, so a stale refresh never stacks on a newer one. It is owned by the job and nothing else writes to it.

Verification

gate	result
cargo test -p devup-mcp --all-features	exit 0 (skills: 15 passed)
cargo clippy --locked --workspace --all-targets --all-features -- -D warnings	exit 0
cargo fmt --all -- --check	exit 0
node scripts/refresh-skills.mjs --check	exit 0 after the re-vendor (was exit 1 before)
YAML parses, bash -n on the extracted step script	both clean

The --check flip from 1 to 0 is the meaningful one: it is the drift this PR both detects and fixes.