fix(h3t): render H3 hexagons crossing the antimeridian

[bbest]

Problem

H3 hexagons that cross the antimeridian (±180°) render as a jagged tear/gap in
add_h3t_source() (and add_h3j_source() / setH3JData()). h3-js
h3ToGeoBoundary() returns such a cell's vertices split between +179° and
−179°, so the resulting polygon ring spans ~358° of longitude. geojson-vt then
mis-tiles that "wraps-the-whole-globe" polygon, leaving a gap of missing/
degenerate cells along 180°.

Fix

The cell→polygon builder (generate() for the Polygon path) now detects
boundaries whose longitude span exceeds 180° and unwraps them — shifting the
negative-longitude vertices by +360° — so the ring is continuous near +180°
before geojson-vt tiles it. geojson-vt's own antimeridian wrap then emits the
cell on both sides of the seam. Non-crossing cells are untouched.

o.generate = h3id => {
  if (o.geometry_type !== 'Polygon') return utils.h3.h3ToGeo(h3id).reverse();
  const ring = utils.h3.h3ToGeoBoundary(h3id, true);
  let min = 180, max = -180;
  for (const p of ring) { if (p[0] < min) min = p[0]; if (p[0] > max) max = p[0]; }
  return (max - min > 180)
    ? [ring.map(p => [p[0] < 0 ? p[0] + 360 : p[0], p[1]])]   // unwrap across 180°
    : [ring];
};

Applied to the three generate() definitions in the bundled
inst/htmlwidgets/lib/h3j-h3t/h3j_h3t.js (addH3TSource / addH3JSource /
setH3JData). The same one-liner applies upstream to
INSPIDE/h3j-h3t src/index.js
— happy to file that PR too so a future h3j-h3t bump keeps the fix.

Verification

Tested against a live global OBIS h3t endpoint
(h3t.marinesensitivity.org, ES50 by H3 cell). Before: a wide jagged tear down
180°. After: hexagons render continuously across the antimeridian on both the
globe and flat (mercator) projections. (Verified with a headless capture; a
faint hairline can remain exactly at the tile boundary under software
rendering — a geojson-vt seam characteristic, not the original gap.)

This is a follow-up to #209 / #199.