Node name decides support status instead of connectivity

[webdevred]

Problem

determineGroup' classifies a vertex as support purely from its name:

determineGroup' brks v
  | isSupportVertex v = Right SupportTree
  | otherwise = determineGroup brks v

with isSupportVertex meaning "the name does not end in a digit". A vertex that looks like a support vertex is therefore treated as one regardless of how many beams actually connect to it, and it is never re-evaluated afterwards. The name becomes a permanent decision.

Whether something is a structural hub should follow from the structure. TRANSFORMATION_DOCS.md defines a support node as "nodes that many beams radiate from", which is a connectivity property, not a naming one.

It is currently applied at the wrong stage

The two stages use the opposite classifier from what the design calls for:

stage	function	classifier
building the forest	newVertexTree (VertexExtraction.hs)	determineGroup, spatial only
rebuilding the forest	groupAnnotatedVertices (Transformation.hs)	determineGroup', name-based

Going by the name while reading a file is defensible: it is how an already-transformed file is recognised. Going by the name while deciding the new layout is not, since that is exactly where the threshold should be applied.

Concrete consequence

bfl_f in the old fender.jbeam had zero beams and zero triangles, and was still classified as a support vertex and placed in the support section, purely on its name. It was in fact test scaffolding rather than geometry, and has since been moved to examples/regression_jbeam/.

Blocked on the threshold

Swapping determineGroup' for the spatial classifier was tested and is not viable on its own: the threshold cannot qualify anything in groups under 25 nodes, which is 97% of real files, so support classification would mostly disappear rather than improve. That must be fixed first.

Two further things surfaced while testing the swap, and would need handling as part of it:

1. Duplicate names. sortVertices renumbers each OMap1 entry from a fresh counter, so two entries that normalise to the same prefix both start at 0. With support vertices no longer separated by name, bfl* and bfsl both normalise to bfl and produced two bfl0 nodes. Threading one counter through the entries with mapAccumL fixes it, and OMap1 already derives Traversable.

2. Duplicated prefix comments. The same collision produces two // prefix group bfl headings in one file.

[webdevred]

#219