refactor(curves)!: replace flo-curves with kurbo

[Copilot]

Related to #203.

monoxide-curves previously re-implemented flo_curves' generic point/curve traits by hand. This replaces that layer with kurbo, keeping only the custom stroked-with-alignment logic that kurbo doesn't provide.

Core types now wrap kurbo directly

• Point2D = re-export of kurbo::Point; Affine2D = re-export of kurbo::Affine.
• Missing helpers (unit_x, translated, mirrored_along, flips_direction, etc.) added via Point2DExt/AffineExt extension traits instead of a full custom type.
• CubicSegment/CubicBezier/builder/iterator rewritten as concrete (non-generic) types backed by kurbo::CubicBez/Line/PathSeg, dropping the generic Point/Num trait scaffolding.

Dropped hand-rolled algorithms in favor of kurbo

• cube_to_quad now delegates to kurbo::CubicBez::to_quads, removing ~250 lines of custom FontForge/naive conversion code.
• Arc length now uses kurbo::ParamCurveArclen::arclen instead of a custom flo_curves-based implementation.
• cube/compat.rs and other pure flo_curves compatibility scaffolding removed.

Stroked-with-alignment logic preserved

• Tangent/normal/join computation for per-point variable-width, aligned stroking (used in glyph generation) is unchanged in behavior, just retyped from custom vector math to kurbo::Vec2.

// Before: generic type implementing flo_curves' Coordinate/Geo traits
let bez: CubicBezier<Point2D> = ...;

// After: concrete type built directly on kurbo
let bez: CubicBezier = ...;
let quads = cube_to_quad(bez, accuracy); // delegates to kurbo::CubicBez::to_quads

Consumer crates (monoxide-script, monoxide-font, monoxide-playground) were updated to drop the now-unnecessary generic parameters and pull in the new extension traits where needed. monoxide-ttf is unaffected, since its QuadBezier<(fword, fword)> usage relies on QuadBezier remaining generic, which is retained.

[rami3l]

Not sure if it's still worth it to keep CubeSegment generic. It looks like QuadSegment is actually generic in the codebase but not for CubeSegment. Maybe a default generic param =Point2D can be used?

[lynzrand]

lgtm, I'll try to let my agent add a =point2d

[rami3l]

@lynzrand BTW do you think CubeSegment needs to be generic? Because our agent decided that it's actually always materialized with Point2D and has thus removed that param.

[lynzrand]

lgtm