crypto/bn256/google: canonicalize coordinates before testing them

[4waan]

big.Int coordinates in the google backend are lazily reduced.. Add and Double write values outside [0, P) and Negative writes a negative yEach commit makes each one of 4 predicates (that read those values as if they were canoncial) agree with the representation it is actually handed.

MakeAffine inverted an unreduced z. ModInverse returns nil when no inverse exists. On the curve that nil went straight into big.Int.Mul and panicked; on the twist the same z has a zero norm, so Invert returned zero and the point at infinity silently became the affine point 0 : 0 : 1. Reducing z first removes the case instead of detecting it: after reduction z ∈ [1, P) at the inversion, coprime to prime P. That holds for any input, including a caller who mutates the big.Ints G1.CurvePoints hands out, which a nil check would only catch after the fact.

MakeAffine returned non-canonical coordinates. The z == 1 path returned without touching x and y, so G1.Neg of an affine point produced a representation MakeAffine would not normalize, and comparing two mathematically equal points by their coordinates was unsound. Fixing it at MakeAffine rather than at Negative covers Add and Double as well. That path now also writes t ( twistPoint.Add never sets it so a point arriving already affine can carry a stale t) and the Miller loop reads t.

gfP2.IsOne tested y through Bits which reports the magnitude so -1 read as 1.

gfP2.Invert discarded the ModInverse result. This one was correct by accident, and the commit says so rather than claiming a bug... the inverse fails only when the norm x²+y² is zero, and P ≡ 3 mod 4 makes -1 a non-residue, so a zero norm forces both components of a to zero and the multiplications wipe the stale value either way. Returning zero explicitly stops that resting on a coincidence, and matches what cloudflare's exponentiation-based inverse and gnark produce for 0⁻¹.

Testing

canonical_test.go adds five tests. Four fail against current master, checked per test in isolation rather than as a batch; TestGFp2InvertZero passes both ways and is there to pin the 0⁻¹ = 0 convention against a future refactor of Invert.

(independent of #38885 and branched from master) that one fixes reachable aliasing in Double, this one touches MakeAffine, IsOne and Invert.. two can be in review in parallel