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…
• the install page pins each platform to the release that actually has it, and the guard asserts every row asset exists under its own tag (#1202) 1f575f80 · dbf3dbe6…diff
• every compiled-in and current-tense loot host moves to loot.build (map #2412, ADR 0099): loot --help names security@loot.build and https://loot.build/trust, ALPHA_PROMISE_URL is https://loot.build/install and the telemetry DEFAULT_ENDPOINT https://loot.build/api/telemetry, so the next release carries them; the site install one-liners, R2_BASE and HOP_BASE (https://dl.loot.build, https://loot.build/dl), the metrics SITE_SCOPE and own-host referrer, the disclosure links on trust, terms, privacy and known-issues, and the install, quickstart and guides pages follow, with the privacy and terms markers moved to 25 September 2026 and re-pinned since readers see the new address; README, CONTEXT.md (the forge door now forge.loot.build), the release checklist, site CI and test fixtures follow, and the two specs carry a note instead of a partial rewrite. the destination census gains build in WEB_TLDS, without which security@loot.build would be invisible to its bare-host clause, and exempts the two shipped lines that tld makes read as hosts (state.build, r.build()) by their exact text; ADR 0074 section 9 says twelve-entry to match. 37 lines still name millerbyte.com outside ADR bodies, evidence, research and scratch, each kept on purpose: dated history, millerbyte.com the site and its @millerbyte/ui tokens, the two noted specs, and relay-era tooling with no successor host, filed as #2438. census red with build dropped from WEB_TLDS, restored; site gate 819 passed and within budget; workspace suite 4559 passed over 142 binaries, 13 ignored (#2418) c5663115 · dbf3dbe6…diff

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.