perf(bp): batched verify_batch_agg via BBB+18 RLC stacking (part of #88)

[tesseract-ripple]

Part of #88 (BP-side only; sigma-side amortisation will land as a
separate PR). Stacked on #104 (single-proof MSM, #100) and #89
(vendored MSM). Only the last commit (01f118ac) is the #88 change.
Review just that commit; the earlier two are already up for review on
their own PRs.

What

New public API:

int secp256k1_bulletproof_verify_batch_agg(
    secp256k1_context const* ctx,
    secp256k1_pubkey const* G_vec,  /* sized for max(m_vec[i]) */
    secp256k1_pubkey const* H_vec,
    unsigned char const* const* proofs,
    size_t const* proof_lens,
    secp256k1_pubkey const* const* commitment_C_vecs,
    size_t const* m_vec,
    secp256k1_pubkey const* pk_base,
    unsigned char const* const* context_ids,
    size_t n_proofs);

Verifies n_proofs aggregated Bulletproofs in a single
mpt_msm_variable_time call via BBB+18 §6.1 random-linear-combination
stacking. Mixed-m batches are fine: G_vec / H_vec are sized for the
largest m and lower-m proofs touch only a prefix.

Equation

For each proof $i$, the same $E_{1,i} + c_i \cdot E_{2,i} = 0$ residual
from #104 holds. The batch verifier checks

$$ \sum_i \rho^i \cdot (E_{1,i} + c_i \cdot E_{2,i}) = 0 $$

with $\rho = H(\texttt{"MPT_BP_VERIFY_BATCH"} ,|, c_0 ,|, \cdots ,|, c_{n-1})$.
Each $c_i$ transitively binds proof $i$'s bytes (incl. commitments and
context_id) via the FS chain, so $\rho$ binds every batch input.

The shared generators $G_\text{vec}$, $H_\text{vec}$, $H_\text{pk}$, $U$
contribute one MSM term each regardless of batch size because their
per-proof coefficients are summed into accumulators before the MSM is
built. This collapses $\sim B \cdot (2n + 2 \log n + m + 6)$ terms down
to $(2 \cdot n_\text{max} + 2) + B \cdot (m + 4 + 2 \log n)$ — i.e., the
dominant $2n$ work is paid once for the whole batch.

Soundness

A single invalid proof in the batch makes its residual non-zero, and
Schwartz–Zippel on the freshly-derived $\rho$ gives $\le n_\text{proofs}/q$
rejection probability for a malicious batch. $\rho = 0$ is rejected
explicitly (negligibly probable).

Refactor

The per-proof derivation (parse, FS $y/z/x$, $\delta$, $y^{-k}$ powers,
IPA round challenges $u_i / u_i^{-1}$, $s_k$ vector, ipa_transcript_id,
$u_x$, intra-proof $c$) is now factored into bp_proof_state_init /
bp_proof_state_free. secp256k1_bulletproof_verify_agg from #104 now
uses the same state setup as the batch verifier; single-proof verify is
just a batch of one with $\rho = 1$.

Perf (Apple M-series, m=2)

Batch size	serial verify	batched verify	speedup
8	13.3 ms (1.66 ms/proof)	3.46 ms (0.43 ms/proof)	3.85×
64	108 ms (1.69 ms/proof)	18.0 ms (0.28 ms/proof)	5.98×

Beats #88's 2–4× estimate; the extra factor is from the
shared-generator amortisation. At $B = 64$, the 256 $G_k + H_k$ slots
are paid once instead of 64 times.

Tests

New tests/test_bulletproof_batch.c covers:

• $n_\text{proofs} \in {1, 2, 8, 64}$ with uniform $m = 2$
• $n_\text{proofs} = 4$ with mixed $m \in {1, 2}$
• positive: each proof verifies individually AND batch verifies
• negative: tamper the last proof's last commitment → batch must
  reject (exercises the shared-accumulator rejection path)
• throughput benchmark vs serial (B=8 and B=64)

All 12 ctests green. Pre-commit + clang-format clean.

Out of scope (tracked separately)

• Cross-proof MSM amortisation for the four compact sigma families
  (also mentioned in *_verify_batch: batched verification for compact sigma + aggregated BP #88) — separate mechanism (no RLC; just shared
  CMPT generators); ship as a follow-up PR.
• rippled-side integration.
• mpt_msm_constant_time for the prover path — mpt_msm_constant_time: constant-time MSM profile for the prover path #87.