mls_planner: cap the surface closing image at the max map span

[jeff-hykin]

A single corrupt point made close_at_z allocate a ~2.1e9-wide byte image; three orphaned mls_planner processes held 220 GB each after a replay.

• voxelize uses f32 as i32, which saturates out-of-range coordinates to i32::MAX
• close_at_z sizes a dense GrayImage from the min/max voxel index of the slice, so that one point stretches it across the whole gap
• new max_map_span_m config (default 500.0); slices wider than it skip closing and pass through unclosed
• regression test a_far_outlier_does_not_allocate_the_gap

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

@@                     Coverage Diff                     @@
##           jeff/fix/ray_tracing_tf    #3643      +/-   ##
===========================================================
- Coverage                    77.78%   77.76%   -0.03%     
===========================================================
  Files                         1293     1295       +2     
  Lines                       123834   123930      +96     
  Branches                     10851    10856       +5     
===========================================================
+ Hits                         96329    96370      +41     
- Misses                       24364    24417      +53     
- Partials                      3141     3143       +2     

Flag	Coverage Δ
OS-ubuntu-24.04-arm	72.78% <100.00%> (+<0.01%)	⬆️
OS-ubuntu-latest	74.61% <100.00%> (-0.01%)	⬇️
Py-3.10	74.61% <100.00%> (+<0.01%)	⬆️
Py-3.11	74.61% <100.00%> (+<0.01%)	⬆️
Py-3.12	74.61% <100.00%> (+<0.01%)	⬆️
Py-3.13	74.61% <100.00%> (+<0.01%)	⬆️
Py-3.14	74.62% <100.00%> (+<0.01%)	⬆️
Py-3.14t	74.61% <100.00%> (+<0.01%)	⬆️
SelfHosted-Linux	35.25% <66.66%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
dimos/mapping/dim_slam/demo_cuvslam_realsense.py	76.92% <100.00%> (ø)
dimos/mapping/odometry_hist.py	97.72% <100.00%> (ø)
dimos/mapping/test_odometry_hist.py	100.00% <100.00%> (ø)
...avigation/nav_3d/mls_planner/mls_planner_native.py	100.00% <100.00%> (ø)
dimos/robot/all_blueprints.py	100.00% <ø> (ø)

... and 4 files with indirect coverage changes

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[greptile-apps]

Greptile Summary

This change adds a configurable maximum span for surface morphology so anomalous distant voxel coordinates do not trigger dense image allocation. Normal bounded surface slices continue to close small holes during both full-map and regional updates.

Confidence Score: 5/5

No blocking failure remains.

The exercised far-outlier path preserved the source surface cells without closing across the oversized span, while bounded full-map and regional updates continued to close the intended hole.

T-Rex Logs

What T-Rex did

• Ran the existing far-outlier surface regression test and authored a public-Planner integration test to exercise the outlier scenario.
• The outlier case preserved all 9 original source cells and left the center hole unfilled, with sources_preserved=true and hole_closed=false; bounded full-map and regional paths both closed the center hole and retained all sources.
• Prepared validation artifacts to support reviewer inspection, including the focused Rust surface-span validation source and two end-to-end validation outputs.

_{Ran code and verified through T-Rex}

_{Reviews (3): Last reviewed commit: "Merge remote-tracking branch 'origin/jef..." | Re-trigger Greptile}

[aclauer]

Ah yes I see the bug now lol

[aclauer]

Would it be better to change the morphological functions to do local operations? The imageproc functions are probably not what we want now that I think of it for this exact reason. Instead we can just do the dilation/erosion on the occupied voxels without allocating the entire 2d slice as an image

[jeff-hykin]

Oops didn't realized you commented. I found it was partially an issue on my end too; a bad TF put the camera far away so it instantiated a really large surface.

we can just do the dilation/erosion on the occupied voxels without allocating the entire 2d slice as an image

That sounds like a good optimization for me.