Normalize offset/offset_origin output longitude to [-180, 180)

[gistrec]

Problem

offset() and offset_origin() return the raw longitude term without wrapping, so any result that crosses the antimeridian leaves the documented LatLng range ("Longitude ranges between -180 and 180 degrees"):

geo::offset({0, 170}, 3'000'000, 90);          // lng = +196.9796, expected -163.0204
geo::offset_origin({0, -170}, 3'000'000, 90);  // lng = -196.9796, expected +163.0204

• offset returns rad2deg(from_lng + d_lng) — each term is in [-π, π], the sum spans up to ±2π.
• offset_origin returns deg2rad(to.lng) - atan2(...) — same issue.

Root cause: the Android SDK normalizes longitude inside the LatLng constructor, so android-maps-utils never needed to wrap these results. This port's constexpr constructor stores values as-is (fmod is not constexpr before C++23), so the normalization was silently lost in porting.

Library-internal math is unaffected (everything is periodic, operator== compares lng modulo 360), but out-of-range longitudes break interop: GeoJSON (RFC 7946), map APIs, DB range constraints, naive component comparison.

Fix

Wrap the output longitude with detail::wrap(lng, -180.0, 180.0) in both functions (same approach heading() already uses for its result). In-range results take the wrap fast path (two comparisons) and are returned bit-for-bit unchanged; only out-of-range results pay for two fmods.

call	before	after
offset((0,170), 3000 km, E)	+196.9796100648	-163.0203899352
offset((0,-170), 3000 km, W)	-196.9796100648	+163.0203899352
offset_origin((0,-170), 3000 km, E)	-196.9796100648	+163.0203899352
offset((0,170), 10° arc, E) — lands exactly on the antimeridian	+180.0	-180.0 (same point)
offset((10,20), 3000 km, NE) — in range	41.320625189337278	41.320625189337278 (bit-identical)

Timings

Apple M1, -O2, Google Benchmark; 10 interleaved base/fixed pairs (run order alternating inside each pair), median of per-pair deltas of per-run medians (15 reps each) — robust against drifting background load. 1000 varied calls per iteration.

benchmark	base ns/call	fixed ns/call	delta
offset, result in range (fast path)	31.9	32.6	+0.70 ns (+2.2%)
offset, result crosses antimeridian	23.6	41.1	+17.5 ns (+75%)
offset_origin, result in range	60.4	62.5	+2.2 ns (+3.6%)
offset_origin, result crosses antimeridian	44.1	58.3	+14.2 ns (+32%)

The crossing-path cost is two fmod calls sitting on the critical path right before the return; it only applies to the (previously incorrect) out-of-range results. The headline percentage looks large because the function itself is only tens of nanoseconds.

Tests

Two new regression tests (suite 34 → 36, all pass):

• Spherical.offset_lng_normalized — east/west crossings against analytically derived expected longitudes (1e-9 deg tolerance), plus the exact-180 landing case (lng ∈ [-180, 180) and position within 1 mm of (0, 180)).
• Spherical.offset_origin_lng_normalized — both crossing directions, plus a round-trip back onto the destination.

Notes

• Behavior change: outputs that previously exceeded [-180, 180] now come back wrapped (and exact +180 becomes -180, the same point). Suggest releasing as a minor version (1.1.0) together with Fix interpolate across the antimeridian #24/Fix offset_origin false nullopt at the asin domain boundary #25/Document distance_to_segment limits; fix epsilon doc and test helper #26 so the distribution channels (vcpkg/xrepo/conan/build2) are re-rolled once.
• interpolate()'s linear fallback can still overshoot the range marginally (~1e-7 deg, or for degenerate antipodal inputs); left out of this PR because Fix interpolate across the antimeridian #24 already touches that exact line — a one-line detail::wrap there can ride along with Fix interpolate across the antimeridian #24 or follow up after it merges.
• docs/api.md: both function sections now state the normalized output range, with an antimeridian example under offset.