Unify getrandom to 0.4 across the wasm dependency graph

[thedavidmeister]

Context

Building any wasm crate in this workspace currently pulls three semver-incompatible majors of getrandom, each needing a different wasm-backend-selection mechanism:

getrandom	pulled by	wasm backend selector
0.2.16	dotrain 6.0.1-alpha.24	js feature (workspace dep in root Cargo.toml)
0.3.3	rain-erc 0.1.1 and rand_core 0.9 ← rand 0.9 ← alloy-primitives 1.6	getrandom_backend="wasm_js" cfg (.cargo/config.toml rustflags)
0.4.2	alloy-primitives 1.6 (directly)	wasm_js feature (getrandom_v04 dep)

After the crates.io cutover (alloy → 1.8.x, alloy-primitives 1.6), the 0.4 edge appeared and broke the standalone crates/common wasm build (the rainix-wasm-browser-test job), because the wasm_js feature was only enabled in crates/js_api. Fixed in PR #2586 by adding the getrandom_v04 (wasm_js) dep to crates/common too — but that leaves the three-major mess in place.

Why we can't reach pure 0.4 today

The binding constraint is alloy, not our crates:

• alloy-primitives 1.6.0 → rand 0.9.1 → rand_core 0.9.3 → getrandom 0.3, while alloy-primitives 1.6.0 itself depends on getrandom 0.4 directly.
• So even if we upgrade everything we own, getrandom 0.3 stays (via alloy/rand) alongside 0.4.

What we can shed by upgrading crates we own:

• dotrain → drop the only getrandom 0.2 edge (removes the js-feature workspace dep entirely).
• rain-erc → drops its own 0.3 edge, but 0.3 still remains via rand_core 0.9.

Proposed actions

• Upgrade dotrain to remove its getrandom 0.2 dependency, then drop the getrandom = { version = "0.2", features = ["js"] } workspace dep.
• Track alloy/rand moving off getrandom 0.3 (rand 0.9 → a release on getrandom 0.4); once alloy-primitives no longer pulls rand 0.9, drop the .cargo/config getrandom_backend cfg and standardize on the 0.4 wasm_js feature only.
• Revisit rain-erc getrandom version alongside the above.

Until alloy moves, the three-mechanism setup in PR #2586 is the correct handling.

[linear]

RAI-712