Y-sorting-threshold comparator is not transitive, causes node-order inversions

[webdevred]

Problem

compareY in compareAV (src-extra/transformation/JbeamEdit/Transformation.hs:342-361) uses a pairwise "fuzzy equality" comparator:

compareY =
  let yDiff = abs $ y1 - y2
   in bool EQ (compare y1 y2) (yDiff > thr)

Two nodes are treated as the same Y-band if their distance is <= thr. This is not transitive: AB and BC does not imply A~C, and sortBy assumes transitivity. When a chain of nodes has consecutive gaps under thr but a total spread over thr, the resulting order depends on merge-sort comparison order rather than actual Y position.

TRANSFORMATION-TODO.md already documents this failure mode for bolide_chassis (the f1l/f5l/f6l cluster) and calibrated the default y-sorting-threshold to 0.05 specifically to avoid it across the existing 238-file survey. That calibration is fragile: it depends on the specific node spacing of whatever files were tested, not a property of the algorithm.

Repro

Using gen4_body (a NASCAR-style body file, not currently in the example corpus) with y-sorting-threshold: 0.1, support-threshold: 20, running --transform produces order inversions exceeding the threshold at both ends of the vehicle:

• nll47 (Y=-1.967, the frontmost node in its group) sorts to the last position in the group, after nll1 (Y=-1.807), a gap of 0.16 which is greater than the 0.1 threshold.
• nrr41 (Y=2.258) sorts before nrr43 (Y=2.139), also a gap greater than the threshold.

Confirmed on both master (d6bc439) and triangles-excluded-from-support-vertices, same result, this code path is unrelated to and unaffected by either branch's recent changes.

Structural integrity (beams/triangles by node position) is unaffected, this is purely a node-ordering/index-assignment defect, not a dropped connection.

Suggested direction

Replace the pairwise fuzzy comparator with a precomputed band assignment:

1. Sort the group by raw Y ascending.
2. Walk the sorted list once, assigning an incrementing integer band index whenever the gap to the previous element exceeds thr.
3. Sort by (band, Z, X) instead of (fuzzy-Y, Z, X).

An Int band index is transitive by construction, so this removes the whole bug class regardless of what y-sorting-threshold value is configured, no more per-file calibration needed.

Test gap

None of the existing fixtures (fender, frame, suspension) reproduce this, and the shared examples/jbeam-edit.yaml test config uses y-sorting-threshold: 0.05 (the calibrated-safe value), so the existing suite would not catch a regression here. Needs either a small fixture with known problematic Y-spacing, or a targeted unit test on the banding function directly.

Fix branch: fix-y-sorting-transitivity

[webdevred]

The banding direction is right, but the gap rule alone breaks down at 0.1, which is a threshold we have already been asked to support.

A new band on every gap over thr means "connected by small steps", not "close together". On the 20 nodes in examples/regression_jbeam/y-sorting-repro.jbeam:

threshold	bands	widest band	nodes in it
0.05	10	0.053	4
0.10	5	0.463	12

At the default it is harmless. At 0.10 twelve of twenty nodes land in one band spanning 46 cm, and inside a band the order comes from Z, so Y stops deciding anything across half the group. ySortingBandingSpec on fix-y-sorting-transitivity runs at 0.1 and asserts that no node is written before another more than the threshold further forward, so it keeps failing even once the comparator is transitive.

Suggested rule

Start a new band when the distance from the band's first node exceeds thr. That replaces the gap rule rather than adding to it, since a gap over thr always puts the node more than thr from the band start. One pass, one integer per node, and the band can never be wider than the value that was configured.

Walked through on the real coordinates of that 12 node band, at 0.1. The accumulator is (band, y of the band's first node):

                     distance to        accumulator
        y            band start         after the step     band
nl18  -1.107         first node         (0, -1.107)          0
nl20  -1.079         0.028              (0, -1.107)          0
nl22  -1.058         0.049              (0, -1.107)          0
nl24  -1.054         0.053              (0, -1.107)          0
nl26  -0.997         0.110  over        (1, -0.997)          1
nl27  -0.958         0.039              (1, -0.997)          1
nl29  -0.898         0.099              (1, -0.997)          1
nl31  -0.838         0.159  over        (2, -0.838)          2
nl32  -0.780         0.058              (2, -0.838)          2
nl34  -0.688         0.150  over        (3, -0.688)          3
nl36  -0.645         0.043              (3, -0.688)          3
nl38  -0.644         0.044              (3, -0.688)          3

The output is [0,0,0,0,1,1,1,2,2,3,3,3], and the final accumulator (3, -0.688) is discarded. Note nl29 at 0.099, nine millimetres inside the boundary and still in band 1. The next node jumps to 0.159 and breaks.

For contrast, the gaps between neighbours here are 0.028, 0.021, 0.004, 0.057, 0.039, 0.060, 0.060, 0.058, 0.092, 0.043 and 0.001. Every one is under 0.1, so the gap rule gives [0,0,0,0,0,0,0,0,0,0,0,0], a single band 46 cm across, and all twelve then sort by height. That is the same twelve nodes as the table above, and it is why they should come out as four bands rather than one.

mapAccumL fits this directly: thread (band, bandStart), emit the band. It is already used four times in Transformation.hs for the same shape.

One other thing

The suggested key (band, Z, X) drops aMeta, which currently outranks Y and keeps nodes with the same metadata together so the emitter does not repeat {...} rows. Dropping it changes output for every file with per-node metadata. Worth deciding on purpose rather than as a side effect, and the same goes for supportNameCompare. Suggest supportNameCompare, aMeta, band, Z, X, changing only compareY.