Use pyvista's public API and int32 face indices

[akaszynski]

Summary

• Build meshes with PolyData.from_regular_faces instead of hand-assembling a vtkCellArray, which removes the direct vtkmodules import.
• Use int32 face indices end to end, including the C++.
• Raise pyvista>=0.42.0, needed for from_regular_faces and regular_faces.

The binding bug

clustering.py imported vtkCellArray from vtkmodules and handed it to a pyvista PolyData. That only holds while pyvista is built on the stock wheel — on another binding it is a different C++ type and SetPolys rejects it with a bare TypeError: SetPolys argument 1:. Rather than route the import through pyvista, from_regular_faces removes the need for it, so there is nothing left to mismatch. A ruff TID251 rule now bans vtk and vtkmodules across the package so it cannot come back.

It also picks fixed-size cell storage when the VTK build supports it, so on pyvista 0.49 the offsets array disappears. On 0.42 to 0.48 the behaviour is unchanged.

int32 faces

clustering.cpp hard-coded int64_t for faces while every other index array crossing the boundary — neighbours, edges, clusters — was already 32-bit. Since nanobind converts a mismatched dtype with a copy rather than erroring, two call sites were already paying that copy silently. Faces are now int32 throughout and subdivision returns int32.

Measured on a sphere with 3 subdivisions and 20000 clusters, the intermediate arrays halve: the faces array 10.7 MB to 5.3 MB, the subdivision output 42.8 MB to 21.4 MB. The returned mesh is unchanged, because create_mesh(clean=True) runs VTK's clean filter, which re-widens it. That is #79.

int32 indices cap input at np.iinfo(np.int32).max points, so _tri_faces_from_poly raises rather than letting indices wrap, and SubdivideTriangles throws std::overflow_error if it would emit more points than an int32 can address. Two pre-existing 32-bit truncations in the same functions are fixed alongside: an int * int allocation size in PointNormals and a uint32_t subscript in RayTrace.

Remeshing output is bit-identical to main — sphere and cylinder, points and faces, maxdiff 0.0. The only difference anywhere is subdivision's faces dtype.

Behaviour change

_tri_faces_from_poly now rejects non-triangular meshes with the same message Clustering.__init__ already uses. Previously a quad mesh whose connectivity happened to divide by three returned silent garbage rather than raising, so this can surface an error for anyone feeding quads without noticing.

AI Usage

Drafted with Claude Opus 5, reviewed by me before pushing. A second Claude reviewed the branch cold and found that the overflow guard I added could never fire — nface_new was an int accumulating to 4 * nface, so it wrapped before the guard read it, and being UB the compiler could drop the check entirely. It also caught that the new triangle check regressed empty meshes to an IndexError. Both fixed here.