feat: attach the assembled site to every release, and let the page name its build

improvise-oujb. A tagged release carried four native tarballs and nothing for
the web; the site shipped only by ci.yml's pages-deploy, on a push to main.

Pages keeps tracking main (user, 2026-09-22: "I like Pages showing the latest
main for now"), so this is a CAPTURE, not a second deployment: the tarball is a
self-hostable copy of the site as of the tag and a rollback target, not what a
visitor to the published site is running. pages-deploy is untouched.

Mechanism is dist's own [[dist.extra-artifacts]], so it survives `dist init`:
`dist plan` under the pinned 0.30.4 lists improvise-web.tar.gz beside the four
platform tarballs and `dist generate` leaves release.yml byte-identical. The
build command is scripts/build-web-release.sh, which calls web/build.sh and
web/assemble.sh -- the same two scripts ci.yml and a developer run, so there is
no second way to build the bundle. Its toolchain pins come from
scripts/web-toolchain-versions.env, which ci.yml's build job now reads too.

`github-build-setup` was measured and does NOT help: it injects into
build-local-artifacts only, which is the wrong job for a global artifact.

The page now names the build it was assembled from in #build-version, stamped
by web/assemble.sh with the same token as the bundles and verified by the same
scripts/assemble-stamp.sh gate. An unassembled tree honestly reads "unstamped".

Verified by running `dist build --artifacts=global` locally: the script ran,
the site assembled, and dist placed improvise-web.tar.gz in target/distrib.
Not verified: a real tag push, which would require cutting a tag.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FC2jVn8Au7E9JPkw6bwXXH

.github/workflows/ci.yml

@@ -56,6 +56,13 @@ jobs:
           workspaces: |
             . -> target
             harness/opfs-contract -> target
+      # One home for the two pins, so the release capture
+      # (scripts/build-web-release.sh, improvise-oujb) provisions the same
+      # versions rather than a second copy free to go stale. The grep keeps a
+      # comment or a blank line out of $GITHUB_ENV, which takes NAME=VALUE only.
+      - name: Pinned web toolchain versions
+        run: grep -E '^[A-Z_]+=' scripts/web-toolchain-versions.env >> "$GITHUB_ENV"
+
       # Pinned release binary rather than `cargo install` (a three-minute
       # source build) or a third-party action. wasm-pack runs its own bundled
       # `wasm-opt`, which is why improvise-wasm-client's Cargo.toml names
@@ -65,8 +72,6 @@ jobs:
       # measured against it locally (346 KB, 120 KB gzipped). Pinning the same
       # version is what makes that local run evidence about this one.
       - name: Install wasm-pack
-        env:
-          WASM_PACK_VERSION: v0.15.0
         run: |
           set -eu
           url="https://github.com/rustwasm/wasm-pack/releases/download/${WASM_PACK_VERSION}/wasm-pack-${WASM_PACK_VERSION}-x86_64-unknown-linux-musl.tar.gz"
@@ -78,7 +83,7 @@ jobs:
       # image ships one, but pinning it is what makes a local run evidence.
       - uses: actions/setup-node@v4
         with:
-          node-version: "24"
+          node-version: ${{ env.NODE_VERSION }}
 
       # The same script a developer runs locally, so there is one answer to
       # "how is the bundle built" rather than two that can drift. It builds all