Optimize dense q1 row dot products

[1sgtpepper]

🚀 What’s this PR do?

Refs #134.

Optimizes dense q_1 row dot products in ZipPlus::prove_f. The prover still computes the same b_j = <poly_comb_r[j], q_1> values and keeps the transcript layout unchanged, but avoids a full Montgomery conversion for every CombR coefficient.

---

📎 Related issues

Refs #134

🧠 Context

q_1 is prepared once, and signed integer coefficients are reduced into raw Montgomery limbs before multiplication. This preserves the existing field-lift result while removing the hot-loop conversion cost.

Benchmarked in Codespace on AMD EPYC 7763, rustc 1.96.0, base 4454d6c.

Benchmark	Base	Head	Change
RAA BPoly<63> batch 1 2^16	33.650 ms	22.667 ms	-32.64%
RAA BPoly<63> batch 2 2^16	67.430 ms	45.548 ms	-32.45%
RAA BPoly<63> batch 5 2^16	173.300 ms	117.600 ms	-32.14%
IPRS BPoly<63> batch 1 2^13	4.5424 ms	3.4673 ms	-23.67%

✅ Checklist

• I’ve tested this locally
• I’ve added relevant docs or comments
• I’ve updated or created tests if needed
• The branch with the feature is named feature/<name>

[albert-garreta]

Hey @Kuhai9801, I think q_0 and q_1 will almost never be Boolean, since they contain values of the form eq(boolean_vector, random_vector), right? If that is the case then it is better to not include this optimization

[1sgtpepper]

You're right. This shortcut only triggers when the original evaluation point slice is Boolean, making the equality table one-hot. In the full protocol the PCS point is r_0 from the multipoint sumcheck, plus folding challenges for the binary PCS, so it is transcript-random and q_0/q_1 are dense with overwhelming probability. That means this PR does not address #134's arbitrary-q_1 Montgomery-reduction hotspot. I'll close or rework this toward the integer-space dot-product approach from #134 unless there is a direct PCS Boolean-opening workload we want to support.

[agarreta]

Why was the PR closed?

[1sgtpepper]

Hi! Created a new one here: #208