feat: add HyperKZG zero-knowledge openings

[markosg04]

Part of the draft Jolt prover stack.

Base: prover-stack/04-hyrax
Head: prover-stack/05-hyperkzg-zk

Adds HyperKZG ZK setup/opening support, tests, and protocol spec.

Validation before submission:

• cargo fmt -q -- --check
• cargo metadata --no-deps --format-version 1
• local gh stack push simulation against a temporary bare remote
• forbidden-path scan for handoffs/, old STACK.md, stack/, and old stack workflow

[0xAndoroid]

Stack maintenance — Pika is rebasing this PR onto #1599 (prover-stack/04-hyrax) and fixing CI as part of the prover stack (#1596–#1606). Rebase + CI summary to follow.

[0xAndoroid]

Stack maintenance — rebased onto #1599 (prover-stack/04-hyrax); CI green.

📚 Stack A: #1596 → #1597 → #1598 → #1599 → #1600 (this PR) → #1601 → #1602 → #1603
📚 Stack B: #1596 → #1597 → #1604 → #1605 → #1606

#1596 and #1597 are shared by both stacks; each PR targets the one before it.

Conflict resolution

• crates/jolt-hyperkzg/src/scheme.rs — combined feat: add Hyrax row commitments #1599's stack-side serde derivation/bounds with feat: add HyperKZG zero-knowledge openings #1600's HyperKZG ZK opening-mode additions.
• crates/jolt-hyperkzg/src/types.rs — kept the stack-side HomomorphicCommitment<P::ScalarField> implementation and added feat: add HyperKZG zero-knowledge openings #1600's AppendToTranscript implementation required by ZK openings.

[github-actions]

Claude code review session started: https://claude.ai/code/session_01SSHUghHhaiXRDU1SxBgbvK

[moodlezoup]

Reviewed the HyperKZG ZK opening protocol with a focus on soundness. The Fiat-Shamir ordering is consistent between prover and verifier across all three challenge derivations (r after appending point/y_out/com; alpha/q after appending the hidden eval-commitment rows; d after appending the witnesses), so no challenge depends on a value committed later. The verifier-side length checks (com.len()+1 == ell, eval-row widths) gate all indexing before the transcript is touched, so a malformed proof can't trigger an out-of-bounds panic. I also re-derived solve_v2_fold_randomizers against the gemini blinding relations and the two-point linear system solves out exactly, and the batched pairing check expands (by powers of d) into the expected per-point KZG opening identities. No soundness or correctness issues found. One minor simplification noted inline.

---

Generated by Claude Code

[moodlezoup]

open_with_mode is only ever instantiated with Transparent — the ZK path goes through open_zk_inner, not here — and the body immediately debug_asserts M::PROOF_KIND == Clear. The M parameter buys nothing; folding this back into a plain open would drop the dead generality. (commit_with_mode's M is fine since it has both Transparent and Zk callers.)

---

Generated by Claude Code