checksum_updater: support PulseEngine universal-wasm tools + surface stale pins

[avrabe]

The weekly checksum updater (tools/checksum_updater) auto-updates only per-OS-binary tools (wasm-tools, wit-bindgen, wac, wasi-sdk, nodejs, wkg, tinygo). Every PulseEngine-owned tool is excluded and falls back to manual edits, so their pins silently drift. This issue tracks making the updater actually work for them.

Why they're excluded today

tool_config.rs only models StandardTarball / SingleBinary / Custom URL patterns keyed by per-OS platform. The PulseEngine tools are universal-wasm components with unstable, changing asset names:

Tool	Registry latest	Pinned (MODULE.bazel)	Released latest	Note
loom	0.3.0	0.3.0	v1.1.13	v0.3.0 is the last release shipping loom.wasm; v1.x ship only compliance reports → blocked upstream (pulseengine/loom#142)
wsc	0.9.0	0.7.0	v0.9.2	asset renamed wsc-cli.wasm → wsc-component.wasm; now also ships per-platform CLIs. Pin lags registry
wasmsign2-cli	0.2.7-rc.2	—	none	no GitHub releases (tag/CI only)
file-ops-component	0.2.0	0.2.0	v0.2.0	current ✅

Concrete gaps / work

1. Add a universal-wasm UrlPattern (single wasm/wasm_component platform, url_suffix is the asset name, no per-OS mapping) and register the PulseEngine tools in ToolConfig::new() instead of the silent "fallback" comment.
2. Per-release asset-existence filtering: skip a release that doesn't carry the expected asset (loom v1.x has none) instead of blindly taking latest_version. Otherwise loom would resolve to v1.1.13 and fail.
3. Surface stale pins: the updater should flag when MODULE.bazel's version pin lags the registry's latest_version (wsc: pinned 0.7.0 vs registry 0.9.0).
4. wsc pin bump 0.7.0 → 0.9.x needs a CLI-compat check of wasm_signing / wsc_attestation wrappers before bumping (asset was renamed and per-platform CLIs added).
5. Document the upgrade workflow in CONTRIBUTING (currently silent).

Found during an automated issue-hunt/version-check pass. Items 1–3 are the core "make the updater handle PulseEngine tools" work; 4 is a separate verified bump.

[avrabe]

First concrete fix from this thread: the wsc 0.7.0 pin was broken on main — wsc.json dropped the wasm_component platform during the per-OS-binary migration (#471), so @wasmsign2_cli_wasm couldn't fetch and the whole wasm_signing tree failed analysis on every PR. Restored in #499 (verified: wasmsign2_wrapper builds again). This also demonstrates gap #3 (stale/broken pins should be surfaced by the updater) and gap #1 (universal-wasm platform support).

[avrabe]

First implementation landed in #502: added UrlPattern::UniversalWasm (gap #1) and VersionFilter::AssetExists (gap #2), registered loom and file-ops-component, and fixed the last_checked parse failure that blocked the updater from reading the hand-authored PulseEngine registry files at all. Verified live: loom correctly stays at v0.3.0 (skips the artifact-less v1.x), file-ops at v0.2.0. Remaining: wsc (dual-natured CLI+wasm), wasmsign2-cli (no GH releases), go (null github_repo), and gap #3 (surface stale pins).

[avrabe]

Dogfooded the merged updater (update-all --dry-run) — runs clean, 0 errors, and the PulseEngine universal-wasm handling works exactly as intended:

• loom → stays 0.3.0 ("newest release shipping loom.wasm", skips v1.x) ✅
• file-ops-component → stays 0.2.0 ✅

Available upgrades it surfaced (third-party): tinygo 0.40.1→0.41.1, wasm-tools 1.246.2→1.252.0, wkg 0.15.0→0.15.1, wasi-sdk 32→33, wac 0.9.0→0.10.0, wit-bindgen 0.55.0→0.58.0, nodejs 24→26 (major).

Remaining gap (gap #3-adjacent): wasmtime is still not managed by the updater — it's excluded in tool_config.rs with the old "has issues with GitHub API calls" note. It's pinned at 43.0.1 while 45.0.1 is out (and relevant to the P3 retarget #500). Worth re-enabling now that the engine is more robust; the original "GitHub API" issue may no longer apply. Adding to this issue's scope.

[avrabe]

Investigated the wasmtime re-enable (gap noted above). The old "GitHub API calls" exclusion note is a red herring — the real blocker is mixed per-platform extensions:

• Linux/macOS assets: wasmtime-v{ver}-{platform}.tar.xz
• Windows asset: wasmtime-v{ver}-x86_64-windows.zip

tool_config.rs's UrlPattern variants assume one extension across platforms (StandardTarball→.tar.gz; a single Custom pattern is one suffix). So wasmtime can't be expressed cleanly — the same reason tinygo excludes Windows. Worse: because the update engine replaces a version's platforms map with only the configured platforms, a naive Custom-pattern config (Linux/macOS only, Windows excluded) would drop windows_amd64 from each new wasmtime version entry on update — a regression, since the bundles support Windows wasmtime.

Proper fix (gap #1-adjacent): add per-platform extension/asset-name support to UrlPattern (e.g. a PerPlatformAsset { platform_mapping: HashMap<String, {url_suffix}> } variant, or let Custom carry the full asset template per platform). Then wasmtime (and tinygo Windows) can be auto-updated across all platforms. Until then, wasmtime stays manually pinned (currently 43.0.1; latest 45.0.1).

Not shipping a Linux/macOS-only wasmtime config, since the Windows-drop regression is worse than the status quo. Flagging as the concrete next step for the updater.

[avrabe]

PR #507 fixes the two remaining root causes (found while dogfooding for #500's tool bump): (1) mixed per-platform extensions — new UrlPattern::PerPlatformAsset (full suffix incl. extension per platform); wit-bindgen converted (Windows .zip), wasmtime added (was excluded). (2) null release name — GitHubRelease.name was non-optional String; GitHub returns null for wasmtime's auto-releases, which is the actual "GitHub API issue" that blocked it. Now Option<String>. Verified live: wit-bindgen 0.55→0.58 (Windows resolved) and wasmtime 43.0.1→45.0.1 (all 5 platforms), both 0 errors. With #502 (universal-wasm) + this, the updater now handles every tracked tool class. Remaining: tinygo Windows (same variant), and applying the actual registry bumps (build-validated, #500 chunk 2).