Extent maxx/maxy initialized with numeric_limits::min() instead of lowest() — breaks bounds when all coordinates are negative

[JorgeGiaco]

In point_io.hpp line 29, the Extent struct initializes:

minx = miny = (std::numeric_limits<double>::max)();
maxx = maxy = (std::numeric_limits<double>::min)();   // <-- bug

std::numeric_limits<double>::min() is the smallest positive double (~2.225e-308), not the most negative value. When every point coordinate on an axis is negative, update()'s std::max never replaces the initial value, so the computed max stays at ~2.225e-308.

Real-world impact (via ODM): on a nadir-only multispectral survey (DJI Mavic 3M, ~3460 images), OpenSfM produced a local frame with all-negative Y (the run also showed the "Negative GSD estimated, this might indicate a flipped Z-axis" warning). During the odm_meshing stage ("Creating DSM for 2.5D mesh"), renderdem reported:

Point cloud bounds are [minx: 1225681.375, maxx: 1228878.625, miny: -2388582.75, maxy: 2.22507385851e-308]
DEM resolution is (45675, 34122611), max tile size is 4096, will split DEM generation into 99972 tiles

The true maxy of the input point cloud (verified with PDAL on odm_filterpoints/point_cloud.ply) is -2385841.0. The DEM height is inflated ~870x, producing ~300,000 tile iterations (3 radii x 99,972 tiles) instead of ~120 — almost all of them [Empty]. The stage still completes correctly (empty tiles are skipped, only real tiles are written), but it takes many extra hours (in our case >12h instead of minutes) iterating over empty tiles.

Suggested fix: initialize maxx/maxy with std::numeric_limits<double>::lowest() instead of min().

Environment: ODM (latest docker image as of June 2026), renderdem invoked by odm_meshing with --output-type max --radiuses 0.1099,0.1555,0.2199 --resolution 0.07 --tile-size 4096.