feat(avm): defensively assert cd hashes

[IlyasRidhuan]

This PR moves us from compute_calldata_hash -> assert_calldata_hash which essentially adds a degree of validation to the calldata hash in the AVM cpp code.

Why tho?

1. Aligns it with other "infallible" pre-requisites to proving, e.g., assert_address_derivation.
2. Somewhat minimises (although not completely) the following prover DOS vector.
   • A sequencer generates proving hints with a bad calldata hash (i.e. H(calldata) != calldata_hash)
   • Gives the hints to a prover agent, since there is no validation the prover agent constructs the entire trace.
   • The proof construction fails because the lookup constraining calldata hash is invalid, all the prover work is wasted
3. It only minimises the attack vector because the prover agent still wastes some work during re-execution, although this should be significantly less than when it gets to tracegen.

Sharp Edges

In TS, cd hash validation is done at the tx validation level. I don't think it is worthwhile to implement the cd hash validation in the TS simulator - so instead I've implemented a validation in the TS fuzzer entrypoint

[IlyasRidhuan]

• feat(avm): avm fuzzer bytecode mutation #19378
• feat(avm): gas mutations #19348
• feat(avm): mutations for accumulated data #19347
• feat(avm): defensively assert cd hashes #19346 👈 (View in Graphite)
• feat(avm): mutate enqueued calls #19315
• merge-train/avm

This stack of pull requests is managed by Graphite. Learn more about stacking.

[fcarreiro]

Just a note that this does make C++ simulation check the cd hashes and fail catastrophically if sth goes wrong. Assuming that the hash is already validated in TX validation, this should be ok (a noop change).

Btw, the sequencer does not generate hints and give them to the prover. The prover itself generates the hints from the TXs and gives them to the agents (all of it under its control).

Once CI passes, lmk and I'll approve.