fix(backend): allow forcing sensor mode via TINYNAV_SENSOR_MODE

[hitomi-krgr]

Problem

Sensor mode is detected once at backend startup via a single ros2 node list probe in _detect_and_init_sensor: if /insight_full is present → looper, otherwise → realsense.

Because /insight_full (the looper SDK node) is often slow to come up, this one-shot probe frequently runs before the node exists, so a looper rig gets misdetected as realsense and the wrong sensor procs are launched.

Change

Add an explicit override:

• When TINYNAV_SENSOR_MODE is set to looper or realsense, honor it verbatim and skip node-based detection.
• When unset, the original detection logic is unchanged — existing deployments are unaffected.
• An invalid value logs a warning and falls back to detection.

Only _detect_and_init_sensor is touched; _sensor_mode semantics and all downstream branches / the /sensor/mode API are untouched.

Why defaulting a looper rig to looper is safe

Even if /insight_full isn't up yet, looper mode only launches looper_bridge_node + planning_node (no sensor driver). The bridge just subscribes to the sensor topics and idles (Waiting for Looper bridge inputs) until the SDK node starts publishing, then bridges automatically — no restart needed.

Deployment

Looper rigs add one line to their compose environment::

      TINYNAV_SENSOR_MODE: looper

RealSense rigs need no change (default detection path).

🤖 Generated with Claude Code

[xiaolefang-dm]

I suggest we use the method from realsense detetion, If the mode is neither looper nor an available realsense, we can either fail fast or wait for the device, I think that would be more reasonable

[hitomi-krgr]

The purpose of this change is to explicitly specify the mode to use right at startup, so it's largely orthogonal to auto-detection. If we want to add auto-detection mechanisms, we can certainly build that functionality on top of this.