docs+test: pin and document the G2 ordering contract for the Groth16 verifier

[pjkundert]

No behavioural change. Existing verifiers, calldata and proofs are unaffected and nothing needs regenerating. This only writes down a contract that already holds, and adds the test that would keep it holding. This cost us a day, so we're documenting it so it doesn't cost someone else.

The contract: the exported Groth16 verifier expects the proof's B component in EIP-197 order ([x_im, x_re, y_im, y_re]), the reverse of proof.json's, and the verification-key constants it embeds are im-first to match. The swap is the CALLER's job, and zkey export soliditycalldata does it for you. End to end this is correct: stock exporter plus stock verifier verifies on-chain, which the smart_contract_tests confirm.

The trap is not a defect, it is an undocumented ABI. Reading the verifier alone, the B assembly looks like it is missing a swap the VK constants clearly received -- there is no hint that the caller is expected to have done it already. Anyone constructing calldata by hand from a proof.json will pass natural order, produce an off-curve G2 point, and get false from a proof that snarkjs groth16 verify accepts off-chain. Off-chain verification uses one internal ordering for both proving and verifying, so it never exercises the discrepancy and gives no warning. Completeness only; soundness is unaffected.

Documented where the problem is actually met, rather than in the root README:

• templates/verifier_groth16.sol.ejs -- a note above the // B block, so it ships inside every generated verifier. That contract is what someone opens when verifyProof returns false.
• cli.js -- the help for both export commands. soliditycalldata states that its output is already in verifier order; solidityverifier points at the note and at the calldata command. That is what is on screen at the moment the calldata is produced.
• README.md -- three lines pointing at those, no more.

And pinned:

• smart_contract_tests: a test feeding exportSolidityCallData output straight into verifyProof. Nothing covered this link -- every existing test builds calldata by hand, so exporter and verifier could drift apart while CI stayed green. Since verifiers are deployed immutably, that agreement is an ABI in the strict sense: changing either side would desynchronise every deployment that already exists from its own tooling. This test makes that impossible to do by accident.

npm test in smart_contract_tests: 8 passing.