Fix: Switch lidar angular filter to LaserScanAngularBoundsFilterInPlace

[bkanator]

Closes PickNikRobotics/moveit_pro#18497

Summary

Switches both lidar filter chain instances in hangar_sim from LaserScanAngularBoundsFilter to LaserScanAngularBoundsFilterInPlace.

The regular filter removes out-of-range beams and rewrites angle_min/angle_max in the published message, so the scan dimensions change message-to-message. InPlace instead marks filtered beams as range_max (the ROS "no return" sentinel), leaving the scan structure — array length, angle_min, angle_max, angle_increment — constant. Nav2's costmap plugins expect consistent scan dimensions; the inf_is_valid: false setting already in nav2_params.yaml discards the range_max beams, giving the same functional result.

Filtering extent

The issue asked whether we're cutting too many beams. We verified with a 1.5m test ring (36 markers every 10°) in simulation:

• Each SICK TIM571 covers 270°. The filter keeps scan angles 45°–225° (π/4 to 5π/4 rad) per lidar, cutting 45° from each end.
• The cut zone (0°–45° and 225°–270°) maps to beams pointing more than 90° rearward in robot frame — exactly where each lidar's beams hit the Ridgeback chassis at 0.3–0.5m.
• The two filtered 180° arcs are complementary: the front lidar covers the forward half, the rear lidar covers the rear half. Combined coverage is 360° with no angular gaps.
• The angles (0.7854–3.9270 rad) are unchanged from the prior commit; only the filter variant changes.

---

Claude agent checks

• code-reviewer (required) — inf_is_valid: false interaction and slam_toolbox header concern reviewed; both are correct/benign in this configuration. Comment added to YAML explaining the range_max/inf_is_valid interaction.
• SKIPPED test-runner (required) — no compilable code changed; only a YAML parameter file
• SKIPPED platform-architect-bot (required when src/** C++/ROS/build-CI changes) — YAML config only, no C++/ROS/build changes