Bump wasm-opt to binaryen version_130 for wide-arithmetic support

[Arshia001]

0.1.30 enables +wide-arithmetic by default (#75), but the pinned binaryen version_123 predates the wide-arithmetic proposal and cannot parse the resulting wasm:

[parse exception: unknown misc operation: 22 (at 0:127094)]
Fatal: error parsing wasm (try --debug for more info)

(misc op 22 = i64.mul_wide_u.) This breaks cargo wasix build post-processing for any project whose dependency tree emits wide-arithmetic ops — a plain axum = "0.8" hello-world hits it. This makes 0.1.30 a broken release for affected projects and should ship as 0.1.31 promptly.

Verified with binaryen version_130 (current latest): parses and processes the same wasm cleanly (including --translate-to-exnref), and the processed axum server runs under wasmer and serves requests. All four platform archives (x86_64-linux, x86_64/arm64-macos, x86_64-windows) exist for version_130 with the same layout, and the per-version cache directory (~/.cache/cargo-wasix/<version>/wasm-opt) means upgraded installs download the new binary automatically.

🤖 Generated with Claude Code

[Arshia001]

Also switched --translate-to-exnref → --emit-exnref here (same semantics for our invocation, but runs the translation at the end of the pipeline regardless of argument order — matches wasixcc). Note this doesn't remove the need for the version_130 bump: the wide-arithmetic failure is a parse error that happens when wasm-opt reads the module, before any pass runs. Verified directly: binaryen 123 with --emit-exnref fails identically (unknown misc operation: 22) on an axum debug build. Both flags have existed since binaryen's May 2024 rename (WebAssembly/binaryen#6592); 123 vs 130 is purely about the parser knowing the wide-arithmetic opcodes that rustc emits since #75.