the same phantom-endpoint bug in Coincident, and the two unguarded branches next to it

Port of snaporca da8d011b87; parity holds (DesignPanel.cpp still exactly 32 divergent
lines). Verified independently on this fork's own rig: full ladder 126/126 against
BuildID 96c697a3, built from this tree.

Reviewing the DistanceX/Y fix for OTHER members of its class found three more live defects
on the constrain toolbar. All four share one root: a branch assumes every picked entity has
two endpoints, and the solver's refusal to resolve a role it cannot find is silent.

COINCIDENT had the identical closest-pair walk over {P0,p0},{P1,p1}. For two Points the
phantom (0,0) pair sits at distance 0, which is the smallest distance there is, so it
ALWAYS won: ptOf(Point,P1) -> 0, ref_ok fails (SketchSolver.cpp:185), constraint dropped.
Not sometimes -- every press.

HORIZONTAL/VERTICAL hardcoded ra=P0, rb=P1 with no type check. With a Point picked the
constraint is dropped by the same mechanism but still STORED: constraints goes 0 -> 1 after
the commit and nothing moves, so the Constraints list shows a dimension that can never do
anything. Worse than refusing -- the panel claims the sketch is constrained when it is not.

ANGLE computed p1-p0 on whatever was picked. On a circle that is (0,0)-centre, so two
circles pre-filled the field with the angle between their centre POSITION VECTORS (178.83
deg for two on the x axis), and accepting it emits SLVS_C_ANGLE on two circle prims.

Both branches now refuse with a message. entity_ends()/closest_ends() are file-scope and
shared by Coincident and DistanceX/Y, so there is one implementation instead of two that
drift.

Two smaller findings from the same review: infer_auto_constraints' roles_of omitted
EllipseArc while heal_coincidences' identical copy has it; and set_point(Circle, Center)
wrote e.center and not e.p0, breaking the "p0 mirrors centre" invariant for the duration of
a live drag.

New rungs D8 and D9, both RED against the shipped binary and green here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY

src/slic3r/GUI/CAD/DesignSketchTool.cpp

@@ -939,7 +939,11 @@ void DesignSketchTool::set_point(int ei, SketchPointRole role, const Vec2d& v)
         e.p0 = v;
         break;
     case SketchEntity::Type::Circle:
-        if (role == SketchPointRole::Center)  e.center = v;
+        // p0 mirrors the centre for circles, which is the convention the solver both writes
+        // (SketchSolver.cpp:110) and restores after every solve (:421). Moving only e.center
+        // left the two disagreeing for the whole duration of a live drag, so anything reading
+        // p0 in that window saw the pre-drag position.
+        if (role == SketchPointRole::Center)  { e.center = v; e.p0 = v; }
         break;
     case SketchEntity::Type::Arc:
     case SketchEntity::Type::EllipseArc:
@@ -2359,6 +2363,12 @@ void DesignSketchTool::infer_auto_constraints(int base, double ang_tol_rad, doub
         switch (e.type) {
         case SketchEntity::Type::Line:   out[0] = SketchPointRole::P0; out[1] = SketchPointRole::P1; return 2;
         case SketchEntity::Type::Arc:    out[0] = SketchPointRole::P0; out[1] = SketchPointRole::P1; return 2;
+        // EllipseArc was missing here while the otherwise identical roles_of in
+        // heal_coincidences (below) has it, so an ellipse arc's endpoints could be WELDED by the
+        // healer but never auto-inferred coincident at draw time -- the same gesture behaved
+        // differently depending on which path ran. Two copies of one rule is how that happens.
+        case SketchEntity::Type::EllipseArc:
+                                         out[0] = SketchPointRole::P0; out[1] = SketchPointRole::P1; return 2;
         case SketchEntity::Type::BSpline:out[0] = SketchPointRole::P0; out[1] = SketchPointRole::P1; return 2;
         case SketchEntity::Type::Point:  out[0] = SketchPointRole::P0; return 1;
         default: return 0;   // circle: centre coincidence handled by Concentric, not here