CLAIM proof data is non-deterministic: `smt_proof_rollup_exit_root` and `rollupExitRoot` unchecked in mainnet path

> Tracking issue for the Cantina finding linked below; confirmed against the current `next` code, with one correction (see note).

On the mainnet CLAIM path, `verify_leaf` ([`bridge_in.masm:564-591`](https://github.com/0xMiden/protocol/blob/next/crates/miden-agglayer/asm/agglayer/bridge/bridge_in.masm#L564-L591)) never reads the 256-felt `smtProofRollupExitRoot` SMT proof, yet all 536 ProofData felts are committed into the note's `NoteId`/`RECIPIENT` (`ProofData::to_elements` / `ClaimNoteStorage::try_from` in [`claim_note.rs`](https://github.com/0xMiden/protocol/blob/next/crates/miden-agglayer/src/claim_note.rs#L135-L156)) — so a prover can vary those 256 felts to build many syntactically distinct CLAIM notes that all yield the identical `LEAF_VALUE`, nullifier and CGI-chain-hash update. Severity: low — the claim's on-chain effect is deterministic; only the note encoding is malleable (no fund loss or double-spend).

Correction to the Cantina write-up: the 8-felt `rollupExitRoot` is NOT freely malleable on the mainnet path. `compute_ger` ([`bridge_in.masm:540`](https://github.com/0xMiden/protocol/blob/next/crates/miden-agglayer/asm/agglayer/bridge/bridge_in.masm#L536-L545)) hashes both exit roots into the GER, which `assert_valid_ger` pins against a registered value, so `rollup_exit_root` is load-bearing and must stay intact. The fix should therefore zero only `smt_proof_rollup_exit_root` on the mainnet branch (a MASM zero-check plus matching Rust canonicalization), leaving `rollup_exit_root` untouched.

Cantina finding: https://cantina.xyz/code/b4ccbfb3-665e-4169-837d-3c7b2f0be458/findings?finding=11

PR status: no open PR in this repo.