Empty-world simulation provides no useful `/scan` evidence, limiting sensor-oracle coverage

[147258369ymc]

Robot Model

Turtlebot4 Standard

ROS distro

Jazzy

Networking Configuration

Simple Discovery

OS

Ubuntu 24.04

Built from source or installed?

Installed

Package version

ros-jazzy-turtlebot4-simulator: 2.0.2-1noble.20260616.091643
ros-jazzy-turtlebot4-gz-bringup: 2.0.2-1noble.20260616.085653
ros-jazzy-turtlebot4-gz-toolbox: 2.0.2-1noble.20260615.145933
ros-jazzy-ros-gz: 1.0.22-1noble.20260616.074726
Gazebo: Harmonic / gz

Expected behaviour

For TurtleBot4 simulation tests that declare `/scan` as a watched topic, either:

1. useful `sensor_msgs/msg/LaserScan` samples should be recorded, or
2. the launch/test profile should explicitly mark scan coverage as disabled/unavailable for empty-world runs.

This would distinguish motion-control campaigns, where scan may be irrelevant, from sensor/hazard campaigns, where scan evidence is required.

Actual behaviour

In empty/minimal-world headless campaigns, the motion-control findings were valid, but `/scan` did not provide useful evidence for sensor or obstacle-related checks.

The previous 1000-round report observed:

```text
All 941 saved error rosbags were parseable and had complete /odom plus /wheel_vels observations.
/scan was absent in all error rosbags because the campaign used the empty world;
this is not a motion-control bug signal.

The latest report similarly concluded:

Empty-world scan false positive: not applicable to the reported acceleration bugs.
Scan absence or no returns are not the triggering oracle class here.

So this is not a motion-control bug. It is an observability/test-profile issue: empty-world simulation can make /scan unavailable or uninformative while users may still assume scan-based behavior is being exercised.

### Error messages

```bash
No terminal crash. Observed analysis result:
/scan was absent in empty-world error rosbags; scan was not the triggering oracle class.

To Reproduce

1. Start TurtleBot4 Standard simulation in an empty/minimal world.
2. Record `/scan`, `/odom`, `/cmd_vel`, and `/clock`.
3. Run a short motion command sequence or motion-control fuzz run.
4. Inspect the rosbag for `/scan` samples and useful finite scan ranges.
5. Observe that motion-control topics are present, while `/scan` may be absent or not useful for scan/hazard checks.

Other notes

This should probably be handled as documentation/profile behavior rather than a controller bug. A useful improvement would be to document two explicit modes:

1. motion-control mode: empty/minimal world, `/scan` optional or marked unavailable
2. sensor/hazard mode: obstacle world, `/scan` required with useful finite ranges