Track structured whole-body motor command gains

Problem

The G1 GR00T WBC path passes per-joint kp, kd, and tau together in several places, but the contract is still represented as parallel list[float] values. That makes call sites noisy and makes it easier for gains/feedforward arrays to drift out of sync with the joint order.

This came up in review on #2300: the refactor should not block that PR, but should be tracked separately.

Suggested Direction

Introduce a structured whole-body command value/message for per-joint motor control, similar in spirit to existing structured geometry messages like Twist or Pose.

Likely surfaces to evaluate:

• dimos.hardware.whole_body.spec.MotorCommand
• dimos.msgs.sensor_msgs.MotorCommandArray
• transport serialization in dimos.hardware.whole_body.transport.adapter
• sim SHM write/read APIs that currently pass q, kp, kd, and tau arrays separately
• whole-body adapters such as G1 real hardware and MuJoCo simulation

Acceptance Criteria

• The public command contract makes q, dq, kp, kd, and tau grouping explicit.
• Per-joint arrays are validated together and cannot silently have inconsistent lengths.
• Existing G1 WBC behavior is preserved.
• Tests cover serialization/transport boundaries and at least one whole-body adapter call path.

Synced from DIM-995 by summer

Start by reading dimos.hardware.whole_body.spec.MotorCommand and dimos.msgs.sensor_msgs.MotorCommandArray, then trace serialization in dimos.hardware.whole_body.transport.adapter. Compare the sim SHM APIs and G1 real-hardware and MuJoCo adapters to identify every separate q, dq, kp, kd, and tau path. Done means grouped validation, preserved G1 behavior, and tests at transport boundaries plus one adapter call path.