turtlebot3: run the simulator, the map and the pose in the same place

[bburda]

Description

Three settings had drifted apart in the headless turtlebot3 profile, and together they stopped the
demo from navigating at all. Each one hid the next, so they had to be found in order.

The simulator was never given the world. gz_args was passed as separate tokens, and launch
joins those with no separator, so gz started with one glued argument:

gz sim -r-s-v2/opt/ros/jazzy/share/turtlebot3_gazebo/worlds/turtlebot3_world.world

No sensor data reached ROS, so AMCL never published the map to odom transform, the global costmap
could not activate, planner_server sat in Activating for 68 seconds and the lifecycle manager
gave up on the whole stack:

[global_costmap]: Failed to activate global_costmap because transform from base_link to map
  did not become available before timeout
[lifecycle_manager_navigation]: Failed to bring up all requested nodes. Aborting bringup.

The map was in the wrong place. turtlebot3_world.yaml carried origin: [-1.76, -2.42] while
the map.pgm it points at ships in turtlebot3_navigation2 with origin: [-10.0, -10.0]. The map
landed about eight metres from the robot, so the spawn point was outside the global costmap and
every plan was refused before it started:

[planner_server]: GridBased plugin failed to plan from (-2.00, -0.50) to (-1.00, -0.50):
  "Start Coordinates of(-2.000000, -0.500000) was outside bounds"

AMCL started somewhere the robot is not. It was configured at (0, 0) while the robot spawns
at (-2.0, -0.5). Headless has no RViz to set the pose by hand, so the covariance stayed high and
the robot could not follow a path.

Related Issue

closes #75

Testing

New tests/smoke_test_navigation.sh runs in the existing turtlebot job, on the stack that job
already starts, so it costs no extra build. Measured against a running demo, 10 passed and 0 failed:

bt-navigator, planner-server, controller-server, amcl   all reach active
lifecycle manager                                        brings up every node
robot                                                    inside the global costmap
sensor origin                                            inside the map
navigation goal                                          accepted, then completes
LOCALIZATION_UNCERTAINTY                                 never confirmed

Each fix was then reverted on its own, to check the test fails when the bug comes back:

gz_args back to separate tokens   5 FAIL  lifecycle x2, bringup, goal rejected, goal not completed
map origin back to -1.76,-2.42    3 FAIL  robot outside costmap, sensor outside map, goal failed
initial_pose back to 0,0          2 FAIL  LOCALIZATION_UNCERTAINTY confirmed, goal failed

The existing tests/smoke_test_turtlebot3.sh still passes 49 of 49 on the same stack.

With all three in place the demo raises its navigation faults for real for the first time: a goal
sent while the stack was misconfigured produced NAVIGATION_GOAL_ABORTED from
/bridge/anomaly_detector/goal_status through the detector itself, not through injection.

Checklist

• Tested locally
• README updated (if needed)