[confidential-transfer] RangeProofs commitment-length checks are inconsistent (Neodyme Nit N04)

[samkim-crypto]

When parsing a rangeproofs into a BatchedRangeProofContext, you always get exactly 8 commitments, enforced by the type-system. This is crucial for security right now, as you later .zip those together with expected commitments, and zip early-aborts when the first iterator is done (e.g. in MintProofContext::verify_and_extract). This could use a comment on the .zip.

In WithdrawProofContext, you have an additional check:

if range_proof_commitments.is_empty()

This isn't required, as there are always exactly 8 fields in there. Gave me a bit of a heart-attack at first though where I briefly thought the other .zip iterators are broken :p

I'd recommend adding a small comment why the .zip is guaranteed to go over all intended pairs. Providing too few signatures is something we have fairly often seen with other protocols, and commitments here are similar.