release: bring binaryen ourselves

wasm-pack downloads binaryen to get wasm-opt, and that download fails on this
runner while the same URL fetched with curl succeeds. wasm-pack uses a
wasm-opt already on PATH when it finds one, so the archive is fetched here
and put there.

Turning wasm-opt off instead would have been the smaller change and the
wrong one: the metadata in crates/bindings/Cargo.toml names the WebAssembly
features to keep the optimisation rather than skip it, and a release that
silently shipped an unoptimised module would be the first thing anyone
downloaded.

.forgejo/workflows/release.yml

@@ -85,6 +85,17 @@ jobs:
           apt-get install -qq -y --no-install-recommends nodejs >/dev/null
           npm install --global --silent npm@^11.15
           curl -sSfL https://rustwasm.github.io/wasm-pack/installer/init.sh | sh
+          # wasm-pack fetches binaryen itself and that fetch dies on this
+          # runner, which is how the first release failed. It uses a wasm-opt
+          # already on PATH when it finds one, so fetch the same archive with
+          # curl — which works here — and let it find that instead. The
+          # version is the one wasm-pack asks for; a mismatch only means it
+          # would download its own again.
+          binaryen=version_117
+          curl -sSfL "https://github.com/WebAssembly/binaryen/releases/download/$binaryen/binaryen-$binaryen-x86_64-linux.tar.gz" \
+            | tar xz -C /tmp
+          export PATH="/tmp/binaryen-$binaryen/bin:$PATH"
+          wasm-opt --version
           cd crates/bindings/npm
           # The declarations are hand-written, so nothing but a type checker
           # would notice them going wrong. build.sh skips the check when tsc