wasm build: relaxed-simd makes output depend on the user's JS engine — intended?

[grepfuldead]

The wasm package is built with +relaxed-simd only (.cargo/config.toml). f32x4.relaxed_madd is spec-permitted to be fused or unfused per implementation, and the NNUE L1–L3 tail is f32, so the eval is exposed. Measured it: 150,000 random legal FENs x {V8/node, JSC/bun, SpiderMonkey} x {relaxed build, strict-simd128 build}, comparing raw evaluate() i32, plus 60 positions at go depth 13 (1 thread), all against the native avx2 build as reference.

Results (one x86-64+FMA host):

• V8 and SpiderMonkey fuse relaxed_madd -> their evals match native avx2 exactly, 150,000/150,000.
• JSC doesn't fuse → bit-identical to a strict-simd128 build on every eval and search.
• Net effect: the same shipped artifact gives different answers per engine 3/150k evals (1cp each), 4/60 d13 bestmoves, 60/60 d13 scores (mean |Δ| 59.5cp).
• Concrete repro: r1bqkbnr/pppppppp/n7/8/8/P1P3PB/1P1PPP1P/RNBQK1NR b KQkq - 0 4, depth 13, 1 thread → V8/SpiderMonkey play d7d5 (−91); JSC plays g7g6 (−79).
• A strict build is bit-identical across all three engines (and sits 1cp off native on 3/150k the same drift class as native scalar vs avx2).

Not a strength issue the bestmove flips are 7–24cp near-ties (one even favored JSC's choice). It's a reproducibility one: same version + same position → different analysis depending on the user's browser, which breaks cross-client repro of user reports. Related: CI's wasm job is build-only nothing ever executes the wasm build, so an engine-side lowering change would also go unnoticed.

For context, #1079's title mentions both a wasm32 and a wasm32-relaxed-simd target, but the config it landed defines only the relaxed one so this may just never have been decided.

Is runtime-dependent output acceptable for the web build, or would you prefer:
(a) strict-only deterministic everywhere, costs the native-parity of fused hosts; or
(b) build both artifacts what lichess's current stockfish-web does (relaxed alongside simd128 with feature detection, never relaxed-only), keeping relaxed as the native-parity fast path? (Frontend selection would be on your side I don't see the consumer in this repo.)

Happy to PR the build side of either, plus a small node-based CI leg that actually runs the wasm build against pinned eval fixtures (pinnable on the strict build, which is the only variant with an engine-independent expectation).