The toolchain tag is the content hash of everything the tarball's bytes depend on

[Japabu]

#392 landed at 6ac57dc2 before this was written, so it goes on its own pull
request. Without it, nothing #392 added to the tarball ever reaches a
consumer.

The gap

toolchain.yml's have step turns an existing content release into
build=no, which skips publish. The key was the four sysroot trees, and #392
moved none of them — it changed the packaging (toyos-ld and TOOLCHAIN go
into the tar) and the linker's install path. So on main today:

old key, at this branch's HEAD:  d8dbd61f8ae95241   → a published release
new key, at this branch's HEAD:  81577c6cac7f8a85   → "release not found"

toolchain-linux-x86_64-d8dbd61f8ae95241 is what every run resolves to, it was
built before #392, and it carries no toyos-ld and no TOOLCHAIN. The
consumer's first ask would have stayed unmet until one of the four trees
happened to move.

The fix

The key becomes the content hash of everything the tarball's bytes depend on:
the four trees plus HEAD:toyos-ld/src, HEAD:toyos-ld/Cargo.toml and
HEAD:.github/workflows/toolchain.yml. Stated at the site, with its price:
a one-line change to the linker or to the packaging mints a new release and so
costs the whole hour-long bootstrap. That is what a content-addressed release
costs and it is the right side to err on — the wrong side ships a tarball whose
contents nobody built.

Eight copies, held identical

The expression cannot be reduced to one place: .github/install-toolchain.sh
runs before there is anything to read it from. Eight copies exist, across
toolchain.yml (which mints the tag), install-toolchain.sh, ci.yml (four),
gate-a.yml and probe-green.yml. A copy left behind asks for a tag nothing
published, and every job in CI installs its toolchain by that tag — so
src/ci.rs::every_toolchain_key_names_the_same_trees holds them: each site's
HEAD: list must equal toolchain.yml's, and a ninth copy anywhere under
.github must join KEY_SITES or red.

Negative control — one copy reverted to the four-tree list:

thread 'ci::tests::every_toolchain_key_names_the_same_trees' panicked at src/ci.rs:553:17:
assertion `left == right` failed: .github/workflows/gate-a.yml names other trees than toolchain.yml does
  left: ["rust", "toyos-abi/src", "toyos/src", "userland/libc/src"]
 right: ["rust", "toyos-abi/src", "toyos/src", "userland/libc/src", "toyos-ld/src", "toyos-ld/Cargo.toml", ".github/workflows/toolchain.yml"]
test result: FAILED. 0 passed; 1 failed

green with all eight moved. The scan states the spelling it closes in its own
doc: git rev-parse … | sha256sum written within 300 characters, which is every
copy the tree has; toolchain.yml's manifest step reads HEAD:rust on its own
and is correctly not matched.

Gates

cargo test --lib          EXIT=0   249 passed; 0 failed; 1 ignored
cargo run -- --clippy     EXIT=0   clippy: 5 invocations clean
cargo run -- --build-only EXIT=0   Boot image: target/bootable.img
cargo run -- --pr         EXIT=0   +14 comment lines against +60 code lines (allowance 15)

src/prose-ledger: src/ci.rs 123 → 137, for the gate above.