feat: Bocklandt reduction and smoothness of quiver moduli

[pbelmans]

Implements Bocklandt reduction (MR1929191) and the classification of cofree quiver settings by Bocklandt and Van de Weyer (doi:10.1016/j.jalgebra.2007.08.019), and applies them to the geometry of quiver moduli spaces.

• strongly_connected_components for quivers;
• bocklandt_reduction and is_coregular for quiver settings, with the reduction steps documented against Bocklandt's paper;
• is_smooth for moduli spaces with properly semistable representations, by checking coregularity of every local quiver setting (MR1972892);
• codimension_singular_locus, using that the singular locus is a union of Luna strata;
• is_cofree, via wedging, prime components, and the classification lists.

Luna-type consumers validate positive multiplicities, nonzero dimension vectors, stable rather than merely semistable summands, and the rigidity restriction on repeated distinct summands. Fixed-shape quiver-setting results are returned as named tuples.

Tests include the ten nodes of the Segre cubic, the accidental isomorphism to Gr(2, 4) for the 6-subspace quiver on a wall, and P^5 for the 3-Kronecker quiver with dimension vectors (2, 2) and (2, 4). Regression tests cover invalid Luna encodings, dimension-vector contracts, and longer Boolean reachability paths.

The nullcone, Lefschetz-motive, and wall-projection functionality formerly included here has moved to the stacked PR #48, so this PR can be reviewed and merged independently. The branch has been rebuilt onto the current main and is mergeable.

[pbelmans]

@giannipetrella This is a Claude-assisted implementation of Raf's smoothness check. Let's review this carefully, and then we have another very useful feature ready.

[giannipetrella]

Three remarks:

• Is it possible to move the Lefschetz/nullcone functionality to another PR, so we can merge this one first?
• I am wondering whether we should enforce __check_dimension_vector across the whole codebase, and if so whether we should have more contract tests like this. I'll open an Issue for this.
• Named tuples seem cool, but do they introduce a performance overhead? If not, this is the first time they appear in the codebase afaik; we should implement them elsewhere as well - I will open an issue for this too.

[pbelmans]

Nullcones have been split off into #48.