Dummy function for BatchEntry has confusing comments regarding commitments

In circuits/src/batch_verify/universal/types.rs file, the BatchEntry::dummy function is implemented and documented as follows:

/// Creates a dummy [`BatchEntry`] for `config`.
pub fn dummy(config: &UniversalBatchVerifierConfig) -> Self {
    let num_public_inputs = config.max_num_public_inputs as usize;
    let len = F::from(num_public_inputs as u64);
    // There's no difference passing `true` or `false` here.
    let has_commitment = true;
    let vk = VerificationKey::default_with_length(
        num_public_inputs,
        has_commitment,
    );
    let proof = Proof::default_with_commitment(has_commitment);
    let inputs = PublicInputs::default_with_length(num_public_inputs);
    Self {
        len,
        has_commitment,
        vk,
        proof,
        inputs,
        commitment_hash: Default::default(),
    }
}

The comment within the function says that there is no difference between passing true or false for has_commitment. However, both VerificationKey::default_with_length and Proof::default_with_commitment take it into account, so it is not true that there is no difference. The actual reasoning here might be as follows.

What is needed here are the padded versions. The functions that are called do not handle padding themselves however, so to ensure something padded is obtained, we pass maximum length, and also that there should be a commitment. As these default functions will use values that correspond with what is used for padding (e.g., the generator of the groups), this will return data that can be interpreted either as valid padding or as valid data for a commitment. In any case, BatchEntry::dummy ultimately returns a BatchEntry where has_commitment is true, so it could be useful to document that in the comment before the function as well.