Changes touching this path

• the releases lag the repo, not the other way round: the version pin stays and forgetting it becomes loud (#839) The ticket assumed the Install page pin lags the releases and asked for a latest/ alias or a derived constant. Measured today, the premise inverts: dl.millerbyte.com/v0.4.2/sha256.sum answers 200 and v0.4.3 AND v0.4.4 both answer 404 — the release pipeline has been quota-blocked since before either was cut (#835, #909), so the repo is two versions ahead of anything a reader can download and RELEASE_TAG = v0.4.2 is CORRECT. That kills both automatic options. Deriving the tag from crates/loot-cli (0.4.4) would point every link on the page at a prefix that does not exist — replacing a page one release behind with a page that is entirely dead, while looking like a cleanup. A mutable latest/ prefix would work and would cost the page the property it exists for: it is a VERIFICATION RITUAL, telling a reader to download an archive and check it against sha256.sum, and under a mutable base the reader cannot say which release they verified. So the pin stays and forgetting it is made loud instead — the ticket second option. test/release-pin.net.test.ts fetches the pinned tag ANONYMOUSLY (a credentialed fetch of these URLs succeeds whether or not the reader path does, which is exactly how #809 twelve dead links survived months of review) and: 1. fails if the pinned tag does not answer 200 — the page core promise; 2. fails if the workspace own version HAS become fetchable while the page still names an older one — the forgotten bump, which is the silent and delayed failure the ticket is actually about. Green today by fact rather than by luck: v0.4.4 is not downloadable, so the pin is not stale, and check 2 arms itself on the first release that succeeds. Both were proven red before being believed — v9.9.9 for the first, a v0.4.1 pin against a fetchable v0.4.2 for the second. No latest/ prefix added to publish-r2.yml: a mutable path nobody is documented against is scaffolding for a use nobody has. Suite 79 passed | 23 skipped. f4e927f5 · dbf3dbe6…

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.