text: Title: [MNT]: Data size consistency checks in _CollectionsWithSizes
  Body: ### Summary
  
  Extracted from https://github.com/matplotlib/matplotlib/issues/12021#issuecomment-530086713. This is a tracking issue so that we can close #12021 but the idea is not lost. It does not need immediate action (and may even be hard to act upon).
  
  There is no built-in size check for the data in _CollectionWithSizes subclasses. For example, for `PathCollection`, one can have 10 paths, 4 sizes and 2 edgecolors.
  
  ```
  import matplotlib.pyplot as plt
  from matplotlib.collections import PathCollection
  from matplotlib.path import Path 
  
  paths = [Path([(0, 0), (0.5, i), (1, 0)]) for i in range(10)]
  # 10 paths, 4 sizes, 2 edgecolors:
  pc = PathCollection(paths, sizes=s, facecolor='none', edgecolors=['r', 'g'])
  ax = plt.gca()
  ax.add_collection(pc)
  ax.set(xlim=(0, 3), ylim=(0, 20))
  ```
  
  ![image](https://github.com/user-attachments/assets/f56b881f-ae42-4050-9460-2fd315b18815)
  
  The behavior is largely undocumented (though some plotting functions mention cycling over properties like colors). AFAICS: The paths effectively define the number of elements sizes and facecolor etc. are cycled through to match the paths (if there are more sizes that paths, the additional sizes are simply unused. If there are less sizes, the sizes are cycled).
  
  Central question: Is this behavior desired? On the one hand, it can be convenient. On the other hand it can be confusing and lead to unnoticed errors.
  
  Note: I suspect that changing the behavior is difficult. (i) would need deprecation, which is cumbersome but possible, (ii) *thing* (e.g. paths) and properties (sizes, facecolors) are currently decoupled. They are brought together at draw-time. If we do size checks, they likely can also happen only at draw-time. We have the individual `set_*` method and size checks in there would prevent any later change of the number of elments: `set_paths(paths); set_sizes(sizes)` would mutually exclude changing the number of elements. Note that this is similar to #26410, but I think we cannot get away with a collective `set_XYUVC` style solution here.
  
  
  
  
  ### Proposed fix
  
  _No response_