CLAIM note doc comment contradicts the zero-padding check in process_global_index_mainnet/rollup

The issue is about a comment in crates/miden-agglayer/asm/agglayer/notes/claim.masm (around line 62) that contradicts the zero-padding check in crates/miden-agglayer/asm/agglayer/bridge/bridge_in.masm (functions process_global_index_mainnet and process_global_index_rollup, lines 338-392). Read the comment and the corresponding assertz code to understand the mismatch. The fix is to update the doc comment to state that the top 191 bits must be zero, aligning with the current implementation and the updated bridge contract. Verify by checking the referenced Solidity bridge changes.

The doc comment on the CLAIM note's globalIndex field contradicts what the code actually enforces, and the contradiction looks like it traces back to an upstream change.

claim.masm describes the field as:

Top 191 bits are ignored (not required to be zero), so indexers must decode it exactly like the contract does

But bridge_in.masm's process_global_index_mainnet / process_global_index_rollup do the opposite — they assert the top 5 felts (191 bits) are zero and panic (ERR_LEADING_BITS_NON_ZERO) otherwise.

I don't think the implementation is wrong here. Checked the reference Solidity bridge: older versions of PolygonZkEVMBridgeV2._verifyLeaf carry a comment saying "global index do not assert the unused bits to 0", which is almost certainly where the Miden-side doc comment's wording came from. But agglayer-contracts v11.0.0-rc.3 (PR #478) changelog lists "Checks globalIndex (to assert that all unused bits are 0)" as a change, i.e. the reference contract was updated to require this. Miden's implementation matches the current contract; the doc comment just wasn't updated to match, presumably left over from when the older, more permissive comment was written.

This isn't exploitable as far as I can tell, current behavior looks correct and consistent with what the bridge is meant to enforce today. But the comment is actively misleading for anyone reading this file to understand the security model, especially since it directly contradicts the assertz two lines below it in bridge_in.masm. Worth fixing so a future change doesn't "fix" the check to match the stale comment instead of the other way around.

Location: crates/miden-agglayer/asm/agglayer/notes/claim.masm (doc comment, ~line 62), vs. crates/miden-agglayer/asm/agglayer/bridge/bridge_in.masm process_global_index_mainnet/process_global_index_rollup (~lines 338-392).

Happy to send a one-line doc fix if this can be assigned to me.