revert: restore the v0.24.0 docs archive source

[jeremi]

Why

The v0.24.0 release is blocked. #800 recorded immutable docs archive digests
for the v0.24.0 docset, then #799 merged after it and changed eight docs
source files. Those changes move the built docset, so the release candidate now
fails at its archive:snapshot --verify-lock step.

Confirmed on ubuntu-24.04 by the release rehearsal against main
(run 32473100032):

archive bundle v0.24.0 does not match its immutable lock entry

Independently confirmed locally with an A/B build of the same docset at both
commits on one machine. version_tree_sha256 is platform-stable: building the
preparation commit on macOS reproduces the Ubuntu-recorded de6afcce… exactly.
At main's head the same field is 157daa66…, so the divergence is caused by
the intervening commits and not by the build platform.

Why a revert rather than re-recording the lock

There is no supported way to re-record an existing entry, by design:

• assertArchiveLockImmutable reports immutable archive lock entry v0.24.0 was changed for any modification to an entry present in the base ref.
• addArchiveLockEntry throws already exists rather than overwriting.
• docs/site/scripts/archive-lock.test.mjs:83 asserts both behaviours.

isLockBackedDocset covers every archived docset, with no carve-out for
availability: candidate, so an unpublished candidate is protected exactly like
published history. Editing the entry would mean defeating a control that has
explicit tests behind it.

release/OPERATIONS.md:255 prescribes the remedy for this situation: when
main advances before dispatch, inspect the intervening commits and rerun the
validators and rehearsal against the new tip, using the new revision only when
the release identity remains accurate. Here it does not, so main has to carry
the content the lock was recorded against.

What this does

Reverts #799. The resulting tree is byte-identical to preparation commit
b2272359d, so the archive rebuilds to the locked digests by construction:

revert tree:   eb6ff11f3a5b26a7b916949a095b600dcc0c5a0a
prepared tree: eb6ff11f3a5b26a7b916949a095b600dcc0c5a0a

Follow-up

Re-land #799 immediately after v0.24.0 publishes. The change itself is
sound; only its timing conflicts with the recorded lock. It ships in v0.25.0.

Flag, not fixed here

CI cannot currently detect this class of breakage. The docs_archives path
filter in .github/scripts/ci_changes.py:647 intentionally lists only archive
tooling and config, so a docs content merge never triggers the job that would
catch an invalidated lock. That is correct for published docsets, whose bytes
are pinned to a tag, but wrong while an unreleased candidate entry is present:
its content resolves to HEAD. Worth considering a rule that treats docs
content as archive-affecting whenever the lock holds an entry whose tag does not
yet exist. That would have failed #799 in CI instead of silently blocking the
release.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2488b42ecb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".