A stale local .archive-bundles entry shadows the published bundle and reports it as a lock violation

[jeremi]

Symptom

npm run check:archives fails with:

archive bundle v0.24.0 digest fdb54a083873ceedd516e0227fd270f0fbd28718ab0d344559f04ba1af812791 does not match lock 7ff1ae9dbc2a02fe4373e96373e72acff07b50eb5f0f541f2ff83f210b4ed1e8

That message reads as "an immutable archive has been tampered with", which is
the most alarming thing the docs build can say. In this case nothing was wrong:
the published release asset matched the lock exactly.

published registry-docs-v0.24.0.tar.gz  7ff1ae9dbc2a02fe4373e96373e72acff07b50eb5f0f541f2ff83f210b4ed1e8
archive-lock.yaml bundle_sha256         7ff1ae9dbc2a02fe4373e96373e72acff07b50eb5f0f541f2ff83f210b4ed1e8

Cause

assembleArchives tries restoreLocalBundle first, which reads
docs/site/.archive-bundles/<id>.tar.gz. That directory is gitignored and is
never invalidated. A bundle left there by an earlier pre-publication
--bootstrap run, built from a working tree that no longer corresponds to
anything published, shadows the real published bundle forever.

Deleting the stale file makes the same command pass, restoring all three
archives from their published bundles:

Assembled 3 immutable archive(s): 3 restored, 0 bootstrapped, 0 supplied separately, 24 outside the publication window.

This is easy to hit on a maintainer machine that ran the release rehearsal,
since bootstrapping is exactly what the pre-publication verification path does.

Suggestion

Make the local-bundle branch distinguish "the cache is stale" from "the archive
is wrong". Options, roughly in order of how little they change:

1. On a digest mismatch in restoreLocalBundle, say so in the message: name the
   path, say it is a local cache, and say to delete it and re-run.
2. On a digest mismatch, discard the local bundle and fall through to the
   published-bundle path; only fail if the published bundle also mismatches.
3. Do not consult the local cache at all when a published bundle is expected,
   and reserve .archive-bundles/ for the bootstrap path that writes it.

Option 1 alone would have turned a long investigation into a one-line fix.