[Cleanup] Remove WASM interpretation providers (zeroj-bls12381-wasm and zeroj-bbs-wasm)

[satran004]

Context & Motivation

zeroj-bls12381-wasm and zeroj-bbs-wasm use Rust implementations compiled to WebAssembly and interpreted in Java via Chicory.

• Pure Java (zeroj-bls12381, zeroj-bbs) and native FFM (zeroj-blst) provide 100% of the functionality with far higher throughput.
• Chicory WASM interpretation is single-threaded and slow for pairing arithmetic.
• Building the WASM modules requires the Rust wasm32-unknown-unknown target and Cargo during Gradle builds.

Scope & Tasks

• Remove zeroj-bls12381-wasm and zeroj-bbs-wasm from settings.gradle.
• Delete zeroj-bls12381-wasm and zeroj-bbs-wasm directories.
• Remove Rust WASM build steps from CI and Gradle tasks.
• Ensure differential test coverage is preserved in pure-Java / blst suites.

Risk Classification

• R0: Module cleanup.
• Reference: docs/zeroj-comprehensive-review-and-readiness-gemini.md (Section 3.1).

[satran004]

Closing as a duplicate of #24 — with one substantive disagreement to carry over, because "remove" and "make opt-in" are not the same thing here.

The factual claims hold. I verified them:

• The .wasm outputs are not git-tracked (only the circom test-vector multiplier.wasm is), so a clean clone must build them.
• zeroj-bls12381-wasm/build.gradle:38-40 wires processResources → copyBls12381Wasm → buildBls12381Wasm, and that last one is Exec: cargo build --release --target wasm32-unknown-unknown. Same shape in zeroj-bbs-wasm/build.gradle:22-26.

So yes — a plain ./gradlew build genuinely requires a Rust toolchain today. That should be fixed.

Where deleting them is a net loss. These two modules are ZeroJ's only independent implementations — zkcrypto's bls12_381 and zkryptium's BBS — and therefore the only real differential-test oracle for BLS12-381 and CFRG BBS. AGENTS.md ranks "strong negative and differential testing" at priority 6 and names "differential tests against independent libraries" explicitly.

Task 4 here says "Ensure differential test coverage is preserved in pure-Java / blst suites." That does not work: blst is not independent of blst, and pure Java is the thing under test. Removing the WASM providers without a replacement oracle trades a build-ergonomics win for an assurance regression.

#24 gets this right — "move to a provider/interop project while retaining valuable differential tests independently."

Recommended under #24: take cargo out of the default build path (make the WASM tasks opt-in), keep the modules and their differential tests, and only relocate once a replacement independent oracle exists.