Add an IMU sensor type backed by each backend's native sensor

[Mark2000]

What this adds

A third mounted-sensor type, ImuSensorConfig, alongside CameraSensorConfig and
LidarSensorConfig — selectable per key like any other sensor:

python -m holosoma.run_sim robot:g1-29dof sensor.imu:g1-pelvis-imu

Readings come from each backend's native IMU: MuJoCo's accelerometer / gyro / framequat on a
mount site, and IsaacLab's Imu on Isaac Sim. Isaac Gym Preview 4 has neither and rejects the
sensor at startup rather than silently creating nothing.

Outputs are linear_acceleration, angular_velocity and orientation, read via
get_imu_data(name, data_type) or as observation terms in managers/observation/terms/imu.py.

24 files, +1496/-31, in six commits; no_sim is green at each one.

The two backends do not measure the same quantity

The most important thing for a reviewer to know, and it is inherent rather than an artefact:

	MuJoCo	Isaac Sim
source	mj_rnePostConstraint -> sensordata	backward difference of mount-point velocity
linear_acceleration	instantaneous, end of last substep	mean over one physics step
centripetal -w^2 r	exact, analytic	O(dt)
under sub-sampling	aliases (spikes in skipped substeps vanish)	attenuates (spikes smear)
angular_velocity / orientation	instantaneous	instantaneous

The divergence is confined to linear_acceleration; neither other path involves dt.

Quantified by the harness's spin check, which compares the two-mount acceleration difference against
the full rigid-body relation alpha x r + w x (w x r) as vectors. alpha comes from a central
difference of the measured w — second-order accurate, so a finer reference than the first-order
quantity under test. Residual is ‖measured − predicted‖, in m/s² and relative to ‖predicted‖:

fps	MuJoCo	Isaac Sim
200	0.0147 (0.36%)	0.0489 (1.22%)
400	0.0068 (0.16%)	0.0278 (0.70%)
800	0.0041 (0.10%)	0.0141 (0.35%)
1600	0.0033 (0.08%)	—
2000 (MuJoCo default)	0.0017 (0.04%)	—

Isaac Sim's error halves per fps doubling — first-order, as a backward difference must be.
MuJoCo's is 3-4x smaller at every rate and flattens toward a floor, consistent with being limited by
the O(dt^2) reference rather than by the sensor.

Consequence: cross-backend parity must be asserted on steady state, never on transients.

An Isaac Sim correction

IsaacLab's Imu divides its velocity difference by the dt of the most recent scene.update
(imu.py:122 then :218), but the difference only advances when .data is touched, and
SensorBase.update does not touch it. Reading at control rate therefore divided an N-step velocity
change by a one-step dt. Against free fall, where the true answer is 0, the error was exactly
-(n-1)*g: 1 settle step gave ~0, 3 gave 19.78, 8 gave 68.84.

sensor_setup.refresh_imus now refreshes each IMU once per scene.update, making the cadences
equal. Two notes:

• The same pattern appears in IsaacLab's manager_based_rl_env.py:182-197 with its imu_lin_acc
  term, while its test_imu.py reads every physics step — the cadence _dt assumes.
• It is invisible at rest, where dv ~ 0 makes the divisor irrelevant.

Cost is ~275 us per IMU per physics step (three PhysX view reads), +20.6% wall clock for four IMUs
in one environment at 200 Hz. Fixed per call, so it amortizes across num_envs;
update_decimation does not reduce it, as that governs only copy-out. Documented on
ImuSensorConfig.

Testing

suite	result
no_sim	1011 passed, 53 skipped
mujoco (full, incl. live harness)	209 passed, 41 skipped
imu_assert.py mujoco / mjwarp 3-env / isaacsim	PASS
isaacgym	skipped — not runnable on this hardware

tests/simulators/imu_assert.py asserts closed-form expectations: |a| == g settled, |a| == 0
in free fall, a rotated mount reading the identity mount rotated by its mount quaternion, and
orientation composing as root (x) mount.

The check worth reviewing is the spin scenario. At rest a lever arm is inert, so
"offset mount == identity mount" is also satisfied by an implementation that drops the offset — it
cannot fail for the bug it appears to test. Spinning in free fall, the offset mount must show the
centripetal term the zero-offset mount cannot see. Verified by zeroing the mount offset while
leaving the expectation in place: the harness fails with "the mount offset looks ignored".

Known limitations

• Isaac Gym is unverified. reject_imus has unit tests, but the whole isaacgym suite skips on
  this hardware. CI is the first real exercise.
• The harness's settled checks are default-physics-rate only. At --fps 1600 an unactuated
  robot still carries real residual contact acceleration (|a| ~ 11.4) on Isaac Sim, so those
  checks fail while free-fall and lever-arm checks pass. REST_ACCEL_TOL is deliberately not
  widened, since its job is catching gravity being wrong.
• imu_orientation is ground truth, not an estimate — a real IMU driver reports no absolute
  orientation, so a policy trained on it will not have the same input on hardware.
• No noise, bias or drift model; no outputs only one backend can produce.

Reviewer notes

• Isaac Sim's gravity_bias is negated from sim.sim.cfg.gravity rather than hardcoded, so a scene
  that changes gravity still reports specific force correctly.
• target_kind="world" is rejected rather than given two divergent behaviours — it would read a
  constant on MuJoCo, and IsaacLab's Imu needs a rigid body to attach to.
• orientation buffers as xyzw to match rigid_body_quat_w while both natives emit wxyz.
  finalize_imu_outputs is the only converter, and it always copies: backends pass slices of a live
  native buffer, already float32 on the Warp path, so casting alone would hand consumers a view that
  mutates under them. It is a function rather than a set_buffer override because quaternion order
  fails silently — the orientation_wxyz keyword states the expected order at each call site.
• refresh_imus runs after both scene.update sites, including forward_kinematics where no
  sim time passes: advancing the history past a state write stops the next sample differencing
  across that discontinuity, at the cost of a momentarily meaningless buffered value.
• backend_cache moves from LidarRecord up to SensorRecord — the same concept for every type.