Bind Surface_mesh_shortest_path (exact polyhedral geodesic) alongside Heat_method_3

compas_cgal.geodesics currently binds only `Heat_method_3` — `HeatGeodesicSolver, heat_geodesic_distances, geodesic_isolines, geodesic_isolines_split`.

CGAL also ships `Surface_mesh_shortest_path`, the exact MMP polyhedral geodesic. It isn't exposed, so downstream projects that need exact distances add pygeodesic — a second compiled dependency wrapping the same algorithm, with its own wheel per platform and no type stubs, next to a CGAL that already contains it.

Why it matters beyond convenience: the heat method is an approximation, so any project validating it needs an exact oracle. Today that oracle must come from outside CGAL, which means the reference and the thing under test have different provenance. That's exactly backwards for accuracy work — and it's the situation that made compas_cgal #73 / CGAL hard to characterise, since the fold in value_at_source_set had to be measured against a foreign implementation.

Shape: Surface_mesh_shortest_path takes source points (vertex or face-barycentric) and answers `distance_to_source_points()` over the mesh, so it fits the existing heat_geodesic_distances(mesh, sources) -> NDArray signature closely enough to sit beside it. A single `exact_geodesic_distances(mesh, sources)` would cover the oracle use directly.