Add wrap_longitude helper for post-processing trajectory longitudes

[vadmbertr]

Motivation

The solver integrates position with pure arithmetic (y_new = y + dt·…) and never normalizes it, so a particle drifting across the antimeridian accumulates an unbounded longitude (181°, 200°, …). That is the correct continuous representation for a trajectory — the forcing interpolation already folds unbounded longitudes for periodic grids, and haversine is periodic in longitude, so nothing downstream breaks. But raw unwrapped longitude is awkward for plotting and analysis.

This adds an optional post-processing helper to fold longitudes back into a canonical window. The solver is intentionally left untouched: wrapping during integration would inject ±180° seam jumps that break line plots and corrupt any finite-difference velocity/dispersion computed along the trajectory.

Change

geo.py: new wrap_longitude(lon, period=360.0, lower=-180.0) → folds into the half-open window [lower, lower + period). Defaults give the [-180, 180) convention; lower=0.0 gives [0, 360). Element-wise, shape-preserving, jit/vmap/grad-safe (jnp.mod(lon - lower, period) + lower). Exported from the package top level.

The docstring warns not to feed wrapped longitudes into finite-difference velocity/distance along a trajectory (the wrap discontinuity corrupts them); wrapping is for presentation only.

Scope

Longitude only. Latitude pole overshoot (lat > ±90, where cos(lat) changes sign) is intentionally out of scope here.

Tests

New TestWrapLongitude in tests/test_geo.py: default [-180,180) window (181→-179, -181→179, 200→-160, 540→-180), [0,360) via lower=0.0, in-window values unchanged, idempotence, shape preservation with a [lon,lat]-column example (latitude untouched), and jit/vmap/grad safety. Full suite: 348 passed, 2 skipped; ruff clean.