GreatCircle.Arc omits the shared antimeridian point when splitting dateline-crossing routes

[MaximeKoitsalu]

Hi,

I’m opening this upstream from Turfjs/turf#3030, where the downstream regression appears to come from arc.

Summary

GreatCircle.Arc() produces incorrect geometry for routes that cross the antimeridian.

When the route is split into multiple line strings, the split segments can end up disconnected because the
implementation does not always insert a matching shared point on the antimeridian (+180 / -180) for both
sides of the split.

In downstream renderers this shows up as broken, disconnected, or visually incorrect great-circle routes
around the date line.

Affected version

• arc@0.2.0

Minimal reproduction

import { GreatCircle } from 'arc';

const start = { x: 139.7798, y: 35.5494 };   // Tokyo Haneda
const end = { x: -118.4085, y: 33.9416 };    // Los Angeles

const arc = new GreatCircle(start, end).Arc(100, { offset: 10 }).json();

console.log(JSON.stringify(arc, null, 2));

Other examples that reproduce this:

• Auckland (174.79, -36.85) -> Los Angeles (-118.41, 33.94)
• Shanghai (121.81, 31.14) -> San Francisco (-122.38, 37.62)

Actual behavior

• dateline-crossing routes can be split into separate segments that do not share a common antimeridian
  intersection point
• this leaves a visible break/discontinuity at the date line
• some long routes also appear not to split into a MultiLineString when they should

Expected behavior

If a route crosses the antimeridian and must be split:

• both adjacent segments should include the same interpolated crossing point on the antimeridian
• the resulting geometry should remain visually continuous
• no segment should retain a large longitude jump across the antimeridian internally

Downstream impact

This breaks flight-path / great-circle visualization for Pacific routes and other antimeridian-crossing
cases in downstream consumers such as Turf.

[springmeyer]

Thanks for the bug report @MaximeKoitsalu