Length variables could be with or without commitment

Several structs used in the codebase contain a field named len or similar. Before the changes reviewed by this audit, it was clear what that field should contain: the number of public inputs. However, with the support for gnark-style commitments, the hash of the commitment is an additional public input, though a public input that is computed by the code from the commitment. It is thus unclear from the name of the field alone whether len counts this last public input or not. This is also not clarified in the comments, for example here for BatchEntry:

/// A single entry in a batch of proofs to check.
///
/// # Note
///
/// This struct holds the *padded* verification key, proof, and public inputs,
/// as well as the original (unpadded) length as a field element. It holds a
/// boolean flag for the presence of a non-trivial Pedersen commitment. The circuit
/// will compute the witness from this struct. It can only be created from
/// a [`UniversalBatchVerifierInput`].
#[derive(Clone, Debug, Deserialize, Serialize)]
pub struct BatchEntry<F = Fr>
where
    F: EccPrimeField,
{
    len: F,
    has_commitment: bool,
    vk: VerificationKey,
    proof: Proof,
    inputs: PublicInputs<F>,
    commitment_hash: F,
}

We recommend to clarify whether len counts the public input from the commitment or not, with a comment or by renaming the field (e.g., to len_without_commitment or similar).