Split aux tables based on size

[robknight]

The aux table holds supporting data for certain operations, including Merkle container and state transition ops, SignedBy, PublicKeyOf, and custom predicate operations. It has a fixed row size, based on the largest possible value. Most aux table entries are quite small - MerkleTreeStateTransitionClaimTarget is 18 field elements, and all others are smaller. However, CustomPredicateVerifyQueryTarget is 314 field elements. Because of this outlier, the table rows are much larger than is needed for typical cases, making lookups more expensive than they need to be.

This change splits CustomPredicateVerifyQueryTarget out:

• General aux table now only carries Merkle / pubkey / signature / state-transition entries — narrower rows, fewer Poseidon constraints per lookup.
• A second table (custom_pred_verify_hashes) stores just the query hash for each CustomPredVerify entry, indexed by the same aux_index.
• verify_custom_circuit looks up the stored hash and compares it to a freshly-computed hash of (statement, op_type, op_args), instead of unhashing a wide row and doing flattened equality.

Both tables are identical in length (every push to one is paired with a None padding push to the other), enforced via helpers on a new OperationAuxTables struct.

This reduces measured gate count by 3445.

[ed255]

If I understand this correctly, the saving comes from replacing:

• an is_equal_flattenable over 314 elements (CustomPredicateVerifyQueryTarget)
  by
• an is_equal_flattenable over 4 elements (HashOutTarget) + an extra lookup over a table of hashes

I wonder if we can apply this change for all cases, and we can move back to a single table.