rounding: record F-034, arc segment counts tip on the last bit

No behaviour change. Comments and a FAILURES entry.

The Y profile builds a section area of 135.572973 against a recorded
135.574, out by 0.001027, while every other value for that case matches
exactly. Three-Fin matches on everything including area.

Isolated by probing the reference inside the pinned toolchain image. The
hull cap is identical to nine figures, the bare union is identical, and a
single filleted pair is identical at 30 vertices and 125.699057 mm2. The
difference appears only when the three filleted pairs are combined, and
the three pairs, which are related by 120 degree symmetry and must be
identical, come back as 125.699057, 125.698029, 125.699057.

Cause proven. The arc segment count is a ceiling on a quantity that is
frequently an exact integer: a 60 degree half-angle at $fn=48 gives
exactly 8. Floating point delivers that as 8.000000000000004 on one
corner and 7.999999999999998 on the others, so one corner gets a whole
extra segment. The half-angles come from the merged polygon, whose
vertices come from the boolean kernel, and BOSL2 clipper and GEOS
disagree in the last bit.

Reproduced unguarded because the reference is unguarded. Rounding the
count before the ceiling was implemented and reverted: it makes the three
pairs identical and fixes Y exactly, and breaks Three-Fin, which had been
matching to the digit. Three-Fin has the same asymmetry and the oracle
records it. BOSL2 tipped the same way GEOS does there and the opposite
way on Y.

Two consequences for the project rather than the code. Some recorded
values encode float noise rather than geometry, so a port that is
geometrically more correct than the reference will fail those cases. And
the tolerance model may need revisiting: VOLUME_MM3 is compared at the
lengths tolerance of 1e-4 despite being area times 100 mm, so a 1e-3 area
difference becomes a 1e-1 volume difference. MASS_G is derived the same
way.

No decision yet. The number of affected cases is unknown and is the only
thing that should drive it, and that is not knowable until build() exists
and all 123 cases can run.

src/mechcomp/geom/rounding.py

@@ -229,7 +229,19 @@ def _circlecorner(points: Tuple[Point, Point, Point],
     scale = r / math.sin(math.radians(angle))
     center = (scale * bx / bn + here[0], scale * by / bn + here[1])
 
-    n = max(3, math.ceil((90.0 - angle) / 180.0 * segs(r, None, fn)))
+    # The segment count is a ceiling on a value that is frequently an exact
+    # integer -- a 60 degree half-angle at $fn=48 gives exactly 8. Floating
+    # point delivers that as 8.000000000000004 or 7.999999999999998 depending
+    # on how the corner was reached, and the ceiling then differs by a whole
+    # segment, changing the enclosed area by about a thousandth of a square
+    # millimetre.
+    #
+    # This is reproduced unguarded because the reference is unguarded. Rounding
+    # first was tried and is wrong: it fixes the Y profile and breaks Three-Fin,
+    # because BOSL2's own output is asymmetric in exactly this way and the
+    # oracle records that asymmetry. See FAILURES.md F-034.
+    raw = (90.0 - angle) / 180.0 * segs(r, None, fn)
+    n = max(3, math.ceil(raw))
     return arc(n, center, (start, end))