Add the factored precompile VM ACE registry

[Al-Kindi-0]

The recursive verifier must use the ACE circuit matching the proof's height-sorted AIR order. With ten AIRs there are 10! = 3,628,800 valid orders, so checking in every circuit commitment or rebuilding the complete registry for each proof is impractical.

This PR makes the registry compact to store and cheap to serve while retaining exhaustive checks over every proof order.

How it works

Each ACE circuit is split into a short order-dependent prefix and a larger common section:

leaf(order) = merge(H(constants | shuffle(order)), H(common))

The factory builds the common circuit once, caches its commitment and the sponge state after the constants, and then emits only the shuffle section for each order. When a protocol change requires minting a new registry from scratch, this reduces the offline leaf-and-root construction phase from 169 seconds with per-order assembly to 58 seconds with the factored encoder (2.9x). Packed hashing and the final two-tier layout reduce that phase further to 37.6 seconds on M4 NEON. None of this full-registry work is performed at process startup or while serving a proof.

The complete tree has 2^22 slots. Instead of checking in its 3.6 million active leaves, the repository stores 4,096 authenticated subtree roots. The complete registry is rebuilt only by the maintenance tool; normal proof serving never performs that work. A serving process authenticates the checked-in row and builds the circuit factory once, then reconstructs only the selected 1,024-leaf subtree for each proof.

The regeneration tool has two roles:

• --check recomputes the complete registry, checks the fast shuffle encoding against full circuit assembly for every order, and compares the result with the checked-in artifacts.
• --write is the rarer minting path. Before replacing protocol constants, it compares every packed leaf with the scalar commitment obtained from fully assembling that order's circuit.

The Miden VM registry moves to the same factored commitment format. Registry roots and relation digests change, so recursive-proof artifacts created with the previous format are incompatible.

Factoring adds an order-dependent shuffle section. This PR also applies a conservative DAG normalization pass that retains only circuit-shrinking rewrites while preserving evaluation. The net size change at this branch tip is:

Relation	EVAL gates	Change	Stream felts	Change
Miden VM	5,176 -> 5,336	+3.1%	5,760 -> 5,920	+2.8%
Precompile VM	9,576 -> 10,640	+11.1%	12,592 -> 13,656	+8.4%

Unlike full-registry minting, this extra work is paid when a recursive verifier loads and evaluates the circuit. If end-to-end profiling shows that cost is material, a follow-up can retain the two-tier registry while investigating unfactored per-order circuits and a different strategy for constructing or serving their authenticated subtrees.

Performance

All figures below use release mode on M4 NEON. The full-registry figures are offline maintenance costs, not per-proof costs:

• Complete registry construction: 37.6 s with Rayon's default 14-thread pool.
• Exhaustive CI drift check: 54.85 s median over three runs.
• Minting new constants: 100.60 s median over three runs; this does not run in CI.
• First lookup in a fresh concurrent process: 29.2 ms, including factory construction and row authentication.
• Marginal registry lookup for each subsequent proof: 14.7 ms with concurrent. The default single-threaded std path takes 106.0 ms warm.

Circuit generation and validation dominate these measurements. Building the Merkle subtrees is less than 1% of the full construction cost.