CI job to rebuild the WebAssembly bundle from pinned sources

[adulbrich]

Split out of #233 (Phase 5), which is otherwise complete.

What exists

public/wasm/ holds eleven .wasm modules and their Emscripten glue, committed to the repository, plus versions.json recording which upstream commit each came from. npm run wasm:versions:check verifies that the recorded versions match what shipped, and that check now runs in ci-web.yml.

What does not exist is a job that rebuilds them. The build recipe lives in public/wasm/README.md and in the wasm.yml workflow on the radiantlab/LibRaw fork, and is run by hand.

Why it matters

Two reasons, and the second is the one that will bite.

Reproducibility. The whole argument for WebAssembly over native bundling was that a Radiance bump is one artifact rather than forty (see #227). That only holds if producing the one artifact is a button rather than an afternoon of remembering which flags mattered. Several of them are load-bearing and non-obvious: -sEXIT_RUNTIME=1, -sINVOKE_RUN=0, -fexceptions (which silently did nothing once, because add_compile_options() only affects targets created after it), -ffp-contract=off, USE_MMAP forced off, OPENEXR_FORCE_INTERNAL_* forced on.

Licensing. The application is GPL-3 and serving .wasm is conveying object code, so the Corresponding Source has to be offered. A CI job that builds the shipped artifacts from pinned sources is the cleanest possible evidence that the published recipe is the one that produced them. See licenses/DECISIONS.md.

Scope

• A workflow_dispatch job that checks out the pinned upstream commits, builds all eleven tools with the Emscripten SDK, and uploads them as artifacts.
• Compare the result against what is committed and fail loudly if they differ, or explain in the job summary why a difference is expected.
• Regenerate versions.json from the commits actually built rather than by hand.

Notes

Deliberately not on every push: the toolchain fetch and the OpenEXR/libtiff/libjpeg-turbo builds take far longer than the rest of CI combined, and the inputs only change when someone bumps a pin. #236 (bumping panlib's Radiance pin) is the next thing that will want this.

[adulbrich]

A new coupling this job needs to respect, introduced by #243 in PR #249.

The persistent RAW-to-TIFF cache keys entries on sha256(source bytes) + "-" + toolTag, where the tag is derived from public/wasm/versions.json:

toolTag = first 12 hex of sha256(dcraw_emu.commit + ":" + emscripten + ":" + dcrawArgs("in","out").join(" "))

That exists so a rebuilt dcraw_emu invalidates cached conversions instead of serving pixels produced by a different demosaic while reporting success.

The requirement for this job: regenerating the .wasm artifacts and regenerating versions.json must be one atomic step. If a rebuild ships new binaries against a stale versions.json, the tag does not change, every existing cache entry still matches, and users are served TIFFs from the previous build indefinitely — silently, with no error and no visible symptom. The app would look correct while the numbers came from different code.

scripts/wasm-versions.mjs already generates the file and npm run wasm:versions:check verifies it. The safest shape for this CI job is: rebuild → regenerate → fail the job if wasm:versions:check reports drift, so a mismatch can never be committed. versions.json already carries the warning that it describes the artifacts beside it rather than whatever is checked out, which is exactly the invariant this job has to preserve mechanically.

Worth adding to this issue's scope rather than discovering later: the failure is invisible at runtime, and the only place it can be caught is here.