feat(mmr): add authenticated rooted-frontier path

[krushimir]

Note

Draft/WIP, opening for visibility. VM-side companion to 0xMiden/crypto#984. Based on main for local interop testing; will rebase/retarget later.

Adds the authenticated Merkle-frontier path to the MMR:

• mmr::root - raw rooted frontier root
• mmr::root_with_len - authenticated (num_leaves, root) pair
• mmr::unpack_frontier - authenticates (num_leaves, root) against advice-provided padded peaks, then loads them so get/add keep working

root alone doesn't bind length (raw roots collide across lengths under empty padding); root_with_len disambiguates, per the 0xMiden/crypto#984 regression. Also adds mmr/hash_primitives benches.

[krushimir]

Follow-up to @huitseeker's benchmark question on 0xMiden/crypto#984. This is for the current PR implementation.

• Root/hash component: rooted-frontier auth is ~2.0x hash_peaks at 10^3 blocks, rising to ~3.0x at 10^6 in hasher rows. hash_peaks is mostly flat (peaks pad to a 16-word floor); the rooted-frontier path grows with bit length.

• get: the standalone win (verifying a leaf directly against the root skips re-hashing the peaks) - is real, but doesn't surface in the tx kernel: unpack_frontier authenticates (num_leaves, root) once, peaks land in the normal MMR memory layout, and every subsequent get opens within that authenticated peak memory, so tx get is unchanged.

• Transaction benchmark: padded proving cost is unchanged in the tested Falcon and ECDSA scenarios. unpack → unpack_frontier adds ~+560 chip rows per tx at bench MockChain scale and ~+1,740 at ~10^6 blocks, staying below the next power-of-two trace boundary in both cases.

• Raw execution: ~+200 clk per tx (<1% Falcon, ~1–2% ECDSA); proving dominates and padded size is unchanged.

• Methodology: standalone VM ExecutionTrace::trace_len_summary for per-procedure costs, applied as deltas to an actual bench-transaction baseline; bench MockChain delta also confirmed by literal in-tx injection. All measured tx scenarios use K=1 consumed note, so multi-note amortization follows from the shared-unpack structure rather than a separate K>1 measurement.

Caveat: assumes this PR's shared unpack/peak-memory representation; per-get root-path verification would be a different transaction shape.

[huitseeker]

Could we either zero the padded peak words here, or assert that they are zero?

unpack_frontier writes all padded words from advice into MMR memory, but root_from_peak_end only authenticates the real peaks before peak_end. So the same (num_leaves, ROOT) can be accepted with different non-zero padding, and a later mmr::pack will hash those padding slots into a different legacy commitment.

[krushimir]

Fixed. unpack_frontier now zeroes the padded peak slots after loading them from advice. The root check still only uses the real peaks, but the memory layout is now canonical, so a later mmr::pack cannot hash non-zero padding.

Added a regression test for this.