Handle `interiorcuts` edge cases

`interiorcuts` shoots a downward ray from the hole's lowest vertex, but rounding to the integer fm grid can cause that vertex to end up outside the parent. In that case the hole is silently dropped. There should be a fallback that does something reasonable.

The correct behavior probably looks like a pinch point (non-consecutive repeated vertex) that isn't necessarily addressed correctly by the method currently in #292.

```julia
Af = Polygon(
Point{Float64}[(-2, 5), (-16, 11), (-12, -4), (-11, -9), (19, -4), (17, -3)] .* 0.37
)
Bf = Polygon(
Point{Float64}[
(14, 10),
(21, 14),
(11, 12),
(18, 20),
(-1, 12),
(-2, 4),
(5, -5),
(6, -11),
(8, 2),
(13, -5)
] .* 0.37
)
xf = xor2d([Af], [Bf])
c = Cell{Float64}("test")
render!(c, xf, GDSMeta())
```
Current result:

Should be:

(If you place `xf` in a CoordinateSystem and use the graphics backend to display it, you will see the correct holes, because the graphics backend negates the `y` coordinate (for Cairo's top-left origin convention) before turning it into polygons, and then all the cut rays do intersect outer contours.)

You can also end up with multiple zero-length edges for a hole touching its parent contour at a point. The geometry is correct but some consumers reject duplicate consecutive points (and there's a pinch point even if you deduplicate).

Reproduce the case using the provided Af/Bf polygons and follow xor2d into interiorcuts, then compare its result with render! and the graphics-backend behavior described. Review the pinch-point handling in #292 and check how zero-length consecutive edges are produced. Done means preserving the expected holes for the example while avoiding rejected duplicate consecutive points.

Written by the indexing model from the issue text.