Fix panic in exterior_paths(): the point ordering isn't a total order

[drietsch]

The problem

GraphPath::exterior_paths() orders the points of the graph before walking them, comparing x values against a tolerance:

if (x_a - x_b).abs() < 0.01 {
    y_a.partial_cmp(&y_b).unwrap_or(Ordering::Equal)
} else if x_a < x_b { Ordering::Less } else { Ordering::Greater }

A tolerance comparison isn't transitive. a and b can be within 0.01, and b and c within 0.01, while a and c are not — so the ordering can report a < b, b < c and c < a at the same time. That isn't a valid strict weak ordering, and sort_by is documented as being allowed to panic when it detects one. Current Rust versions do:

thread '...' panicked at library/core/src/slice/sort/shared/smallsort.rs:854:5:
user-provided comparison function does not correctly implement a total order

Every path arithmetic operation ends in exterior_paths(), so path_add, path_sub, path_intersect, path_cut and the rest can all reach it. It needs a path with enough closely spaced points that arrive in no particular x order — a monotonic sweep doesn't trigger it, which is probably why it has gone unnoticed, but jittered or generated artwork does. Measuring the comparator in isolation over random points clustered in a narrow x band: at 24 points ~70% of sets panic, and by 128 points it's ~98%.

The change

Quantise x into tolerance-wide buckets instead of comparing pairs against a tolerance. Points that are close together still sort together and are still ordered by y — the intent of the original comment is preserved — but the grouping becomes an equivalence relation, so the ordering is well defined. total_cmp is used so the result stays a total order even if a coordinate is NaN.

The two tests added with this build a tall, narrow path whose vertices jitter within a 0.05-wide band; both panic without the change and pass with it. The rest of the suite is unaffected: 791 tests pass, 0 failures.

Unrelated finding, happy to file separately

While tracing this I noticed GraphPath::round() is a no-op:

// src/bezier/path/graph_path/mod.rs:583
self.points[point_idx].position.round(accuracy);

Coordinate::round is fn round(self, f64) -> Self, so this computes the rounded coordinate and discards it — the same on the two cp1/cp2 lines below it. Nothing catches it because Coordinate: Copy makes discarding the result legal rather than a move error, and the method isn't #[must_use]. The nine callers in the arithmetic modules are all correct; only the body is affected. The fix would be self.points[point_idx].position = self.points[point_idx].position.round(accuracy);.

I left it out of this PR because making it actually round would change output for existing users, which felt like your call rather than something to fold into a crash fix. Glad to open an issue or a separate PR, whichever you prefer.