Cache per-level FFT twiddle tables

[ValarDragon]

This extracts the portable FFT-cache component of #290. It deliberately omits
the evaluator batching and x86-only field-arithmetic dependency from that PR;
the evaluator-only component regressed the one-action Mac screen.

What changed

• Retain contiguous per-level butterfly twiddles alongside the existing flat
  proving-key twiddle arrays.
• Use those tables for the larger FFT levels, while retaining the existing
  strided scalar loop for small levels.
• Share every retained allocation across proving-key clones.

The tables are constructed eagerly by keygen_pk; proof creation and explicit
commitment preparation do not lazily initialize them. The proof format,
transcript, and verifier behavior are unchanged.

Performance

All latency measurements below were made from ca2f53c with candidate
2847a60. This branch is rebased onto current main at e1cbe51d, which also
contains the prepared-MSM fold from #320, so I am not treating the older timing
data as a post-#320 measurement.

The harness was prepared_first_proof.rs at SHA-256
3db624e0908ddb5d87f6d95dbedb619f2efadc662600551e26051403562c8828, built
with Rust 1.97.1, release ThinLTO, --no-default-features, and
--features circuit,multicore. Runtime worker counts were set only with
RAYON_NUM_THREADS.

On a 10-core Apple arm64 host with 10 Rayon workers, 100 fully counterbalanced
control/candidate pairs gave:

Orchard k=11	Control	Candidate	Delta	Bootstrap 95% CI
1 action	55.490 ms	55.389 ms	-0.101 ms (-0.181%)	[-0.289, +0.090] ms
4 actions	140.558 ms	139.764 ms	-0.794 ms (-0.565%)	[-1.123, -0.465] ms

The one-action result is neutral; the four-action improvement is resolved and
agreed across candidate-first and candidate-second positions (-0.740 ms and
-0.847 ms). Three thermally or competitively contaminated attempts were
rejected by the runner and repeated.

On an x86_64 Linux host with six Rayon workers, 100 ABBA pairs per action count
were neutral: -0.217 ms (-0.174%), bootstrap 95% CI [-1.461, +0.951] ms at one
action, and +0.161 ms (+0.047%), CI [-0.966, +1.280] ms at four actions.

The benchmark's four-run action schedule aliases key-generation block position
with action count. The apparent Mac key-generation deltas reversed sign between
one and four actions, so the run does not identify a setup benefit or cost and
none is claimed here.

Memory and correctness

For the Orchard k=11 domain, the additional per-level caches retain 585,656
bytes per independently generated proving key under stable 64-bit accounting:
585,312 bytes of field elements, 312 bytes of Vec descriptors, and 32 bytes
for the two added Arc handles. This excludes allocator metadata, allocation
rounding, and Arc reference-count headers. Cloned proving keys share the
allocations.

Seeded control and candidate proofs were byte-identical on both hosts:

• 1 action: d2af1db7354fd2d31b3d3ae8108708e5a31b8cfd944f8961c72e21e99d8ae2c7
• 4 actions: a0d03e72a4e71464550f28fab844cd1a777065fd791a9659dc394fc8985e0f01

The rebased branch passes the full zakura-halo2-proofs test suite with the
multicore feature, no-default-features checks both with and without
multicore, formatting, and the cache-size/sharing regression test across the
current Orchard domain.

There are no public or pub(crate) API additions or signature changes, no
dependency or feature changes, and no new unsafe code. The cached values are
fixed domain roots and do not depend on witnesses, challenges, or secrets.

[v12-auditor]

Note

Complete: Audit complete. No review-worthy issues remain after automated review. One finding was auto-invalidated.

Open the full results here.

Analyzed one file, diff e1cbe51...b3ffaae.