CommonSubdivision::interpolateEdgeLengthsA/B: resolve source faces unambiguously on Delta-complexes

[designbynumbers]

interpolateEdgeLengthsA/B resolve the source face containing each common
subdivision edge with sharedFace() on the two endpoint SurfacePoints.
On a Delta-complex this is ambiguous: two vertices can be joined by more
than one edge, and sharedFace() may return a face adjacent to the wrong
connecting edge. The endpoints are then interpreted as corners of that
face, and the returned "length" is the length of an entirely different
edge. Since intrinsic triangulations routinely become Delta-complexes
after edge flips, this affects ordinary usage.

This PR resolves the source face through the common subdivision's own
provenance data instead:

Face f = sourceFaceB[e.halfedge().face()];   // was: sharedFace(tail, tip)

(and sourceFaceA[...] in interpolateEdgeLengthsA). Every common
subdivision edge lies inside the closure of its adjacent faces' source
faces, and corner-based barycentric coordinates within a single face are
well defined even on a Delta-complex, so this resolution is unambiguous.

How to verify

The minimal failing case is a single edge flip on a tetrahedron: flipping
edge ab creates a second edge between c and d, parallel to the
existing one. The common subdivision itself is fine, but
interpolateEdgeLengthsB reports the length of the wrong cd edge:

// load tet.obj as (mesh, geom)
IntegerCoordinatesIntrinsicTriangulation tri(mesh, geom);
tri.flipEdgeIfPossible(tri.intrinsicMesh->edge(1));

CommonSubdivision& cs = tri.getCommonSubdivision();
cs.constructMesh();

// Ground truth: every CS edge lies in a single face of both meshes, so
// extrinsic positions interpolated across mesh A give exact lengths
VertexPositionGeometry csGeo(*cs.mesh, cs.interpolateAcrossA(geom.vertexPositions));
csGeo.requireEdgeLengths();

EdgeData<double> lengthsFromLenB = cs.interpolateEdgeLengthsB(tri.edgeLengths);
for (Edge e : cs.mesh->edges()) {
  EXPECT_NEAR(csGeo.edgeLengths[e], lengthsFromLenB[e], 1e-5);
}

On current master (b34974d) this fails with a worst per-edge error of
1.195 on the unit tetrahedron (flipping edge 1 or 5; the other edges pass
by luck of face-iteration order). With the fix the worst error is ~1e-15
for every flip choice. The PR includes this check as a test
(IntrinsicTriangulationSuite.CommonSubdivisionEdgeLengthsDeltaComplex),
which exercises all six flip choices and both the A and B variants.

interpolateEdgeLengthsA has the identical latent problem when mesh A is
a Delta-complex input, though the common simplicial-input case masks it;
the PR fixes both for symmetry.

As with #248, we checked this against the int-tri-updates branch: the
affected code is identical there, so the fix applies cleanly to both
lines and is independent of that branch's reworked tracing.

🤖 Generated with Claude Code (Claude Fable 5)