[Groth16/Interop] Align pure-Java and blst G2 projective JSON policy

[satran004]

Summary

The pure-Java and blst Groth16 JSON verifiers accept different representations of G2 projective points. Pure Java normalizes a general nonzero Fp2 z; the blst path rejects every z != (1,0).

This consolidates K3 F1, Grok G16-002, and C-06. It is a provider-semantics/canonical-encoding gap, not a demonstrated ordinary snarkjs interoperability failure: snarkjs emits affine z = [1,0].

Evidence

• General normalization: zeroj-bls12381/.../G2Point.java:37-48
• Pure-Java verifier decode: Groth16BLS12381PureJavaVerifier.java:118-132
• blst affine-only check: Groth16BLS12381Verifier.java:181-212
• Existing provider-parity coverage exercises an ordinary affine vector, not adversarial projective envelopes.

Design decision

Define the canonical snarkjs-JSON profile and select one behavior:

1. accept valid projective encodings and normalize them identically in both providers; or
2. require affine canonical JSON and reject non-affine inputs identically in both providers.

Given ZeroJ's canonical-serialization priority, accepting multiple representations requires an explicit compatibility reason. A valid projective test vector must transform X and Y consistently with Z under ZeroJ's coordinate convention; changing Z alone changes the point.

Acceptance criteria

• JSON point profile and coordinate convention are documented.
• Pure Java and blst accept and reject the same G2 JSON envelopes.
• Tests cover affine, valid non-affine, zero-Z, noncanonical field values, malformed Fp2 components, off-curve, wrong-subgroup, and infinity cases.
• Normal snarkjs proof/VK fixtures continue to verify.
• On-chain/importer semantics are checked for unintended divergence.

Risk

R2 — canonical parsing and provider-consistency boundary. Low practical interoperability severity; no proof soundness break demonstrated.