feat: add poly-proof-core crate

[themighty1]

This PR adds the core of the Quicksilver polynomial proof protocol.

Also adds a #[poly_kernel] proc macro that turns context-aware circuits into straight-line kernel constraints.

Benchmarks

Polynomial set emulating the SpeakUp 50K-CPU-step constraints — 11.6M evaluations evaluations (~232 per step), single-threaded, using Gf2_128.

Phase	Native (hardware-accelerated)	WASM (v8)	Slowdown vs Gf2_64
Prover	0.715 s	10.47 s	~1.4× native / ~2.8× WASM
Verifier	0.713 s	10.18 s	~1.3× native / ~2.9× WASM

_{Native = RUSTFLAGS="-C target-cpu=native" (lights up pclmulqdq for Gf2_64); WASM = wasm32-wasip1-threads on
v8.}

[themighty1]

migrated to v2 API and ready for review, @sinui0

[sinui0]

This still constructs an in-memory DAG and pays for dispatch while traversing it. It should be possible to define the circuit statically using the Context abstraction and actually evaluate the polynomial constraints with it (the same way that the gate-by-gate API works)

[themighty1]

I had a look at that, and my current feeling is that the gains of direct Context execution may be outweighed by:

• losing the Var x Var optimization.
  The Var × Var fast path that exploits subfield-aware muls (scalar_mul for the witness side, full-E mul only on the MAC side) depends on the info in the AST. Direct Context execution erases that info — every Mul becomes a full convolution, or we add a runtime operand-kind check inside Context::mul that's the same dispatch in different clothes.

There may be other concessions too (closure storage + re-invocation per evaluation, loss of pre-computed d_max / scratch layout, etc.).

I'd rather revisit once profiling tells us which cost dominates, especially in the WASM environment.

@sinui0

[themighty1]

@sinui0 , implemented straight-line kernels, also updated the description with the bench results. Ready for review.

[sinui0]

This seems like it is severely more complex than it ought to be, especially the introduction of proc-macros.

The implementation still has an in-memory circuit model, but all our circuits are statically determined. The polynomial proof functionality should get built into the existing Prover/Verifier types in zk-core-new, as we will be using a composite of polynomial constraints + degree 1, all with the same setup and delta.

My recommendation would be to clean slate this and restarting with the Context abstraction. I would assume this functionality is a relatively small addition (<2k LOC).

One simplification worth keeping in mind is that we don't need it to be fully generic, we know exactly what field sizes we want: F_2 and F_2^64.

[themighty1]

I took a look at this inline-trait approach, and I don't think we can both retain the scale_by_subfield optimisation and avoid doing the dispatch without extra complexity.

Adding specialised methods or typed Exprs to PolyContext can recover some of the optimisation without runtime dispatch. But it's a manual / type-driven version of what the lifter does automatically.

[themighty1]

Enforcing 128-bit field size. Updated the description with benches for Gf2_128 and slowdown vs Gf2_64.

[themighty1]

Closing in favor of #429