Unify getrandom to 0.4 across the wasm dependency graph #2599

Context

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

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.