fix(ros2): pluggable state extractors (joint_state / imu / odom)

[rylinjames]

Summary

Replaces #121's fragile hasattr duck-typing with an explicit --state-msg-type CLI flag that dispatches to one of three pure-Python state extractors. The 10-DOF odom path lines up end-to-end with the quadcopter preset's state_dim so silent shape mismatches surface loudly at the right layer.

state_msg_type	ROS2 message	What's extracted	DOF	Used by
joint_state (default)	sensor_msgs/JointState	.position	7 (franka)	Arms — unchanged
imu	sensor_msgs/Imu	.orientation quaternion xyzw	4	Drones (partial state)
odom	nav_msgs/Odometry	pose + linear twist	10	Drones (full state)

The 10-DOF odom state matches exactly what EmbodimentConfig.load_preset("quadcopter").state_dim returns after #132 — pinned by a cross-layer test so future drift in either side breaks at CI time.

Adapted from #121

@DsThakurRawat opened #121 trying to fix the same bug (the bridge couldn't read drone state via ROS2). The original PR had two real problems I've fixed here:

1. Duck-typing was fragile. hasattr(msg, "position") is True for JointState (correct) but False for nav_msgs/Odometry (which nests its position under msg.pose.pose.position). The PR's logic would silently fall through with _last_state = None for the most important drone topic. Replaced with an explicit msg-type registry.
2. The IMU-only state was 4-DOF — incompatible with the quadcopter preset's 10-DOF state. Without velocity in the state, the policy can't damp or correct drift; the bridge was wired up to silently produce useless inputs. Added the odom path which gives full pos+quat+linear-vel and matches the preset by design.

Credit for the conceptual direction (drones need a different state extractor than arms) preserved via Co-Authored-By on the commit.

What I built

• _STATE_EXTRACTORS registry in ros2_bridge.py — three pure-Python functions (no rclpy needed), unit-testable with SimpleNamespace mocks on any machine.
• _resolve_state_msg_class() — lazy-imports the right ROS2 message class (so arm deployments that don't have nav_msgs installed still work fine; the import only happens when you actually use --state-msg-type=odom).
• --state-msg-type CLI flag on reflex ros2-serve with validation + helpful error on unknown types.
• One-time state-dim mismatch warning — when the loaded embodiment's state_dim doesn't match what the extractor produces (e.g. you point a quadcopter preset at the IMU extractor by mistake), the bridge logs once instead of silently feeding garbage to the policy.
• Graceful malformed-message handling — catches AttributeError/TypeError from the extractor (e.g. user pointed --state-msg-type=imu at a topic publishing JointState) and logs instead of crashing the node.
• Updated --state-topic help text to point drone deployments at /mavros/local_position/odom (correct full-state topic) or /mavros/imu/data (orientation-only fallback).

Closes / supersedes

• Supersedes fix(ros2): support IMU state vector for drone embodiments #121 (closing with credit note)
• Unblocks: docs(ros2): add MAVROS IMU topic to ros2_bridge.py docstring #122 (MAVROS docstring), docs: add MAVROS topic hint in README ROS2 section #124 (README ROS2 hint) — both can now reference --state-msg-type instead of trying to fake message-type detection inline

Test plan

• pytest tests/test_ros2_bridge.py — 24 new + existing tests pass (1 pre-existing test TestServeRos2Flag fails on main already due to CliRunner subprocess sys.path issue — unrelated to this PR)
• pytest -k "embodiment or safety or guard or preset or ros2" — 225 passed, 4 unrelated skips
• Quadcopter preset's state_dim (10) verified to match the odom extractor's output length (10) by a dedicated cross-layer test
• Live smoke against an actual ROS2 install (deferred — no MAVROS testbed available locally; the unit tests cover the duck-typing failure mode fix(ros2): support IMU state vector for drone embodiments #121 had, and the structure follows the existing bridge patterns)