Choose the sorting axes per part instead of always banding on Y

[webdevred]

Today

compareAV in src-extra/transformation/JbeamEdit/Transformation.hs sorts every group the same way: Y band first, then Z, then X. y-sorting-threshold decides where a band breaks, and x-sorting-threshold (#235) adds a column pass inside a band.

That order is right for a body shell, where a band is a station along the car and the nodes in it form a vertical stack. It is wrong for a small panel, where the part is one shell and the nodes form columns across the car instead.

What the parts ask for

Three parts of the same vehicle want three different readings, and two of them are the same rule with the axes swapped:

Part	Groups on	Walks along
hood	X columns	Y
front bumper	X columns	Z
body	Y bands	Z

On the hood that gives the order the frontmost node first, then back along the column, then a new column. On the front bumper the columns are vertical stacks and the walk is upward. The body is what the tool already does.

Direction is not a setting, but it is not the same for both axes. The walk runs in growing coordinate, bottom to top in Z and front to back in Y, which is what compareAV does today. Columns are taken from the outside in, so the one nearest the fender comes first and the one nearest the centre line last.

That second half is a change. X is compared raw today, in the tie break (compareAV) and in the column pass from #235, so the left side runs from the centre outwards while the right side runs from the outside in. Comparing the distance from the centre line instead makes the two sides read the same, and the right side already reads that way by accident.

Numbering does not change: the index runs on across a column boundary and a new column keeps the same prefix, which is what the tool does today.

Proposal

One key for the axis order, defaulting to what the tool does now:

y-sorting-threshold: 0.05
sort-axes: [Y, Z, X]

Read as group, walk, tie break. The hood is [X, Y, Z] and the front bumper [X, Z, Y]. The threshold applies to whichever axis groups.

The value differs per part, so it needs to be settable per part:

sort-axes: [Y, Z, X]

overrides:
  - parts: ["*_hood", "*_hatch"]
    sort-axes: [X, Y, Z]
  - files: ["*_fb.jbeam"]
    sort-axes: [X, Z, Y]

An override carries the same keys as the base and the last match wins, so the specific rules sit at the bottom. Matching on the part name rather than the file name is the safer default, because one file can hold several parts. The config is read once from the working directory (exe/jbeam-edit/Main.hs) and applyTransform runs transform on the named file alone, so one override applies per run. The neighbouring files that updateOtherFiles rewrites only follow the renamed nodes and carry no transformation config, so nothing has to be resolved inside that loop.

Deriving the axes instead of configuring them

Worth saying explicitly, because it was the first idea and it does not hold. The walk axis is readable from a group's own extent: a flat column extends in Y, a vertical one in Z. The grouping axis is not. Splitting the body on X gives four columns that each span the whole length of the car, which would reorder the whole file rather than leave it as it is. Counting how many distinct coordinates a part has per axis does not separate the three cases either.

So configuration first. An auto value for the walk axis can come later, once it has been measured against the order the stock files were written in.

Fixtures

The hood and bumper files this is based on are not in the repository, so nothing here can be asserted in a test yet. Adding them under examples/regression_jbeam/ would make the wanted order checkable, the same way y-sorting-repro.jbeam carries the body positions.

Part of #69.