fix: the sweep only touches what a newer key superseded, and the registry is told once

[rgdevment]

Two audits, and between them one bug that would have cost a working cache and
several that would have cost a release.

The sweep would have deleted a live cache

main carries two npm caches for Linux-x64, not one, because a setup-node
key holds the hash of its lockfile and nothing that says which lockfile:

key	lockfile	who reads it
c1fc7352… 128 MB	app/package-lock.json	window, coverage
dbd76d3b… 3 MB	package-lock.json	prose
945f725e… 123 MB	the app one, a version back	nobody

The grouping put all three in one family, kept the newest and deleted the other
two — including the 3 MB one the CI had read two hours earlier. setup-node has
no restore-keys for npm, so a missed exact key is a total miss, and the next
push would rewrite it and delete the other: a see-saw, for ever.

The sweep now touches rust only, grouped by the key rust-cache actually
restores by — without either trailing hash. That is provably safe: GitHub
answers a prefix restore with the most recently created match, so everything
older under it is unreachable by definition. It also fixes a quieter miss: a
toolchain bump used to mint a family of its own and survive the sweep, which is
exactly the 2.8 GB generation that broke the budget in the first place.

The old ^(.*)-[0-9a-f]{8}$ would have caught any future key from any action
that happened to end that way. The new one is anchored to v0-rust-.

A fork could trigger the sweep

workflow_run's branches filter reads the branch of the run that triggered
it, and a fork's pull request can name its branch main. The job now also
requires the triggering run to be a push from this repository. No foreign code
was ever reachable — workflow_run checks out the default branch — but a
stranger could fire the sweep at will, which with the bug above was a way to
evict the cache.

It also declares contents: read for its own checkout rather than relying on
the public-repository exception, and no longer reports every delete failure as
"already gone": only the registry's own not-found message is benign, and
anything else now fails the job instead of passing green having swept nothing.

workflow_dispatch with dry_run defaulting true was added because a
workflow_run job cannot be tested before it is on the default branch.

The registry listing

• mcp_config.command now carries ${__dirname}/. The reference host only
  substitutes ${...}; nothing in it resolves a bare relative path against the
  extension directory. Today's client happens to set the working directory, but
  that is undocumented.
• Republishing a tag was a permanent red job — versions are immutable and
  validate does not notice — so the job now asks the registry whether the
  version is listed and stands down if it is.
• mcp-publisher is pinned to v1.8.1 and its checksum verified. It was being
  downloaded unpinned into the one job holding id-token: write.
• validate moved to the gate, where a refusal costs a job instead of arriving
  after the release is announced.
• The bundle's hash is checked against the release's own SHA256SUMS before it
  is listed. A wrong hash publishes without complaint and leaves that version
  uninstallable for ever.
• A prerelease no longer builds a bundle that nothing validates, and the upload
  carries if-no-files-found: error like the other four.

And three the audits asked for after that

• One description. It lived twice, at different lengths — 62 characters in
  the manifest an installer reads, 85 in the listing a searcher reads. The
  manifest now takes it from server.json, which the registry already treats as
  canonical.
• One repository name. The download URL, the manifest's homepage and its
  author all follow ${{ github.repository }} now. A rename used to break the
  URL silently.
• A tag stops leaving caches behind. release.yml writes three npm caches
  under refs/heads/refs/tags/v* on every release — 384 MB for v1.20.0 — and a
  tag ref is used once, so nothing will ever ask for them by key. They are swept
  by ref. Reaching them needed a trigger the main-branch sweep does not have, so
  the job also runs daily, which picks up the other known leak: a pull request's
  cache written by a job still in flight after the pull request closed.