fix(tool-support): measure a Fusion holder by the shape it exported

[JustinSGray]

Found by @dementive in toolpath-template#11. That PR is against the copy of this exporter that lived in the template before it moved into this package, so it cannot land there; this is the same finding against the code that now owns it.

The defect

Autodesk defines a holder's gaugeLength as the height below the gauge line, so it is a reading of the segment stack rather than a fact standing beside it.

The measured arm already worked that way — belowGageLine makes the cut and the last vertex is the answer. The published arm did not: it wrote the vendor's own gaugeLength against a stack built by fromPublished from the vendor's dimensions, and on a V-flange holder those are two different lengths.

REGO-FIX publishes B4, nose to gauge line, beside B3, nose to the flange face, and B4 - B3 is 48.4 mm on every BT 30 — the gauge-line-to-flange distance from the vendor's own standards table. B3 is what fromPublished can draw, because no vendor publishes the shape of the flange above it.

So a BT 30 collet chuck went out declared 98.4 mm below the gauge line and drawn 50 mm long. assemblyGaugeLength is the stickout plus that figure, so the tool was placed 48.4 mm from the gauge line it was drawn against.

The fix

The stack's own height is what is exported, on both arms. The vendor's figure is reported instead of written:

• where the two disagree, a dropped note on holder.gaugeLength naming both numbers;
• where the vendor publishes none, the holder no longer goes out without the key — its shape is fully drawn, so its height is known — and a filled note says the number was read off the geometry;
• a nose-datumed profile still omits gaugeLength entirely, because its silhouette is the whole holder, taper and retention knob included, rather than the part below the gauge line.

fromPublished now accumulates that height as it places the steps rather than summing it back off them: a segment's height has already been converted into the export's unit and rounded, and adding those up would put a conversion and six decimal places between the stack and the number meant to measure it.

Why no test caught it

Both fixtures covering this — here and in the template — published a projection and a gaugeLength that were equal, so nothing could tell the two readings apart. The existing test even asserted the identity as though the stack had proved it:

the heights sum to the gauge length because the stack stops at the gauge line

It summed to 50 because the fixture said 50 twice. That comment is corrected, and a describe block added for a holder where the two differ. Four of its five cases fail against the previous behaviour; the fifth covers the agreeing case and passes on both, which is the point of it.

Downstream

@toolpath/tool-support is consumed by toolpath-template's catalog through app/shared/fusion-input.ts. Its fixture has the same projection === gaugeLength blind spot, and one of its tests asserts the old 'the vendor publishes no gauge length' warning, which this changes. That follow-up lands there once this releases.

Checks

tool-support 340 passed, app-support 21, tool-drawing 174. check-types across 9 packages, lint:js, knip, fusion:verify and format:check all clean. Full pnpm check not run — it needs Docker for generate:check and a Chromium install for the Playwright suite, neither touched here.

Minor bump: exported values change.