[BUG]: Select tools don't select all points within area when selection crosses the antimeridian

Description

When a scattermap (or densitymap) view crosses the ±180° antimeridian the box-select and lasso-select tools do not select points that are visibly inside the drawn region. The selection contains only points from one side of the antimeridian, depending on where the map is centered.

Screenshots/Video

https://github.com/user-attachments/assets/bcd538c6-c24e-4c98-9e54-0860d87c6ef9

Steps to reproduce

• Create a scattermap trace with points that straddle ±180°, e.g.:

  {
    "data": [{
      "type": "scattermap",
      "lat": [-36.85, -18.14, -16.5, -13.3, -13.83, -21.14],
      "lon": [174.76, 178.44, 179.9, -176.2, -171.77, -175.2],
      "mode": "markers",                          
      "marker": { "size": 10 }
    }],
    "layout": {
      "dragmode": "select",
      "width": 900,
      "height": 600
    }
  }
  

• Pan so that all points are visible around the antimeridian
• Draw a selection box that visually encloses all six points
• Observe that the plotly_selected event either fires with an empty selection or with only the subset of points on one side of ±180°

Notes

• Root cause suspicion: src/plots/map/map.js:625 (updateFx) builds the selection rect from invert(pxpy) which calls map.unproject, returning [lng, lat] in [-180, 180]. When the two corners of the drag straddle ±180°, the resulting rect has xmin > xmax (e.g., [[179, ...], [-179, ...]]). Downstream selection code assumes xmin < xmax, so the rect either matches nothing or matches the "wrong" 340° arc. The per-point normalization in src/traces/scattermap/select.js:27 (Lib.modHalf(lonlat[0], 360)) doesn't help because the rect coordinates themselves haven't been unwrapped.
• Fix likely lives in src/plots/map/map.js updateFx / fillRangeItems — unwrap the rect's xmax (add 360°) when xmax < xmin, so downstream xmin < lon < xmax (with lon similarly unwrapped when needed) matches all enclosed points
• Also verify the lasso path (poly.map(invert)), which has the same underlying problem: consecutive polygon vertices can jump ±360° across the antimeridian