Gracefully handle missing GitHub release binaries for wasm-bindgen-cli

[emilbonnek]

Problem

When wasm-bindgen publishes a new version to crates.io, there's a window before the corresponding GitHub release (with prebuilt CLI binaries) is available. During this window, cargo update can pick up the new crate version in Cargo.lock, but Trunk fails with a 404 when trying to download the CLI binary.

I hit this with 0.2.123 — there was roughly a 1-hour gap between the crates.io publish and the GitHub release binaries appearing. I filed wasm-bindgen/wasm-bindgen#5190 and the maintainer confirmed it was a mid-release timing issue.

Current behavior

As I understand it, Trunk resolves the wasm-bindgen-cli version by reading Cargo.lock (or Trunk.toml / Cargo.toml), then constructs a GitHub releases download URL for that exact version. If the URL 404s, the build hard-fails with no fallback or actionable error message.

Suggestions

A few ideas, not mutually exclusive:

1. Fallback to cargo install wasm-bindgen-cli — if the binary download 404s, build from source. Slower, but always works.
2. Check GitHub releases API first — before downloading, verify the release has assets. If not, fall back to the most recent version that does, or to cargo install.
3. Better error message — at minimum, a 404 could suggest pinning the version in Trunk.toml ([tools] wasm_bindgen = "0.2.122") and explain that release binaries may not be available yet for the latest crate version.

This is an unlikely issue to hit — it requires cargo update during a short release window — but when it does happen it's confusing and the error gives no hint at what's going on.