feat: add cycle shape

[Furox-Art]

Design summary

shape: cycle turns a container into a ring: its direct children are placed with their centers on a circle (first child at 12 o'clock), and edges between them are routed along that circle as exact circular arcs whose endpoints are trimmed to each child's visible border.

Layout (d2layouts/d2cycle):

• The core layout engine (dagre/elk/tala) runs first, so any nested content inside the children is fully laid out. Each child is then moved onto the ring together with its descendants, and internal/cross-child edge routes are translated along so nothing detaches.
• Arcs are built as cubic Bezier chains with the canonical circular-arc control offset k = 4/3·tan(Δθ/4), split into segments of at most 90°, so the drawn path is a perfect circle through the existing IsCurve path renderer (no renderer changes needed).
• Endpoints are computed by intersecting the ring with the child shape's geometry: rectangular children exit at the box border (bisection), non-rectangular children (circle, hexagon, diamond, ...) at their actual perimeter, with a TraceToShapeBorder fallback. Arrowheads therefore land exactly on the visible outline, which is what shape: cycle #1578 asks for.
• Edges take the shorter way around the ring. On a two-node cycle, opposite edges take opposite semicircles instead of overlapping.
• The container renders like a normal container (rounded rect), so style.fill, style.stroke, multiple, 3d, double-border, fill patterns, labels and icons all work unchanged.

The name follows the issue discussion (cycle, not radial, keeping radial reserved).

Reviewing

New e2e fixture (e2etests/txtar.txt → cycle-diagram), goldens for dagre, elk and tala:

• e2etests/testdata/txtar/cycle-diagram/dagre/{board.exp.json,sketch.exp.svg}
• e2etests/testdata/txtar/cycle-diagram/elk/{board.exp.json,sketch.exp.svg}
• e2etests/testdata/txtar/cycle-diagram/tala/{board.exp.json,sketch.exp.svg}

The fixture covers: a 4-node ring (the case from the issue), a ring of circle/hexagon/diamond children plus a reverse edge, a ring with nested content (x: {p -> q}), a cross-child edge (x.p -> y), container styling, and a two-node ring with edges in both directions. Reviewers can re-render with TA=1 go test ./e2etests -run 'TestE2E/txtar/cycle-diagram' -v, or paste the fixture board into the playground.

Unit tests: d2layouts/d2cycle/layout_test.go (radius sizing, ring placement, arc circularity + border trimming, nested-content preservation, cross-child edge attachment, two-node semicircles).

How this differs from #2760 and #2806

Both rival PRs share the same core approach (circle layout + circular arcs); this PR is a superset of the stronger one (#2806) with the following differences:

• Shortest-sweep routing. cycle-diagram: keep arcs circular at node borders #2760 and shape: cycle: preserve routes across child containers #2806 always advance clockwise, so a reverse edge like b -> a is routed the long way around (e.g. a 240° arc through the other children). Here every edge takes the shorter sweep, and on two-node rings opposite edges split into disjoint semicircles.
• Tala goldens. cycle-diagram: keep arcs circular at node borders #2760 and shape: cycle: preserve routes across child containers #2806 only ship dagre/elk fixtures, so their txtar case fails on the tala subtest that TestE2E/txtar runs; this PR includes tala goldens.
• d2scenebuild registration. Master's newer scene renderer has its own shape switches; neither rival registers cycle there (paged exports would fall into the typed-shape default path). Registered in all three rectangle cases.
• No changes to the shared SVG pathData curve code. cycle-diagram: keep arcs circular at node borders #2760 rewrites the curve branch used by every d2 diagram (with unreachable branches and dead fallbacks), which is a regression risk for all existing curves; exact Bezier control points make that unnecessary here. cycle-diagram: keep arcs circular at node borders #2760 also skips the core layout entirely (children with nested content are never laid out and would panic in FitToGraph's bounding box), renames unrelated files, and leaves unused helpers.
• Rendered container. cycle-diagram: keep arcs circular at node borders #2760's cycle type hits no drawShape case, so the container is invisible and all container styles are dropped; here it renders as a normal container in both SVG and scene renderers.

Validation

• go build ./..., go vet on touched packages, gofmt clean
• go test ./d2layouts/d2cycle/ -v — 5/5 pass
• go test ./e2etests -run 'TestE2E/txtar$' — pass (all fixtures, dagre+elk+tala)
• go test ./e2etests — full e2e suite passes

/claim #1578

Disclosure: This PR was authored by @Furox-Art (AI-assisted). Happy to adjust anything.

[Furox-Art]

Hi! This PR is blocked waiting for review/approval. Could you please review when you have a chance? The changes are ready and all local checks pass. Thanks!

[Furox-Art]

Friendly ping — this adds a cycle shape. Ready for review; happy to adjust anything. Thanks!

[Furox-Art]

Hi! I rebased this onto current master (f2f2863d8), and it still merges cleanly with no conflicts.

Both CI runs for the new head are sitting in action_required (ci run 37272228670, Release archives run 37272228987) because workflows need a maintainer's approval to run for my fork. Could someone approve them? I can't verify the branch beyond go build + go vet locally, and I'd rather not land this without CI's eyes on it.

Contents unchanged from what you already saw: a cycle shape (arrowheads + cycle in the shape registry) plus the layout/drawing wiring. Happy to adjust naming, defaults, or split the commit if that helps review.