Validate Opendubs as the first mobile-base consumer #85

Outcome

Use Opendubs as the first external consumer of ssrobot's mobile-base description and command contract, and record that commitment in the architecture before the next consolidation gate.

Context

The M1 audit found that MobileBase and BaseTwistCommand have no external consumer in Geodude or ADA. They are being retained because Opendubs is now being built with two OpenArm manipulators, a custom pan-tilt head, and a custom mecanum mobile base.

This issue supplies the named consumer and milestone required by #82. It does not add mobile-base inference: Opendubs should declare its base explicitly.

Scope

• Add an Opendubs robot package whose portable description contains the four unbounded wheel hinge joints and an explicit MobileBase declaration.
• Declare the planar base-twist capability and the observation channels needed by simulation and later hardware.
• Validate the package with ssrobot doctor and ssrobot inspect as an installed wheel.
• Exercise BaseTwistCommand through the M2 MuJoCo runtime using the same neutral command contract intended for hardware.
• Keep mecanum kinematics and calibration in the runtime/profile layer. Do not encode global chassis pose as bounded X/Y joints or require detailed roller contact in the canonical model.

Acceptance criteria

• docs/architecture.md names Opendubs and M2 as the first external consumer of MobileBase and BaseTwistCommand.
• The installed Opendubs package loads without robot-specific ssrobot code and reports its bimanual arms, pan-tilt head, four wheel joints, and mobile base without ambiguity.
• A planar BaseTwistCommand is accepted by MujocoRuntime and produces the documented base-frame vx, vy, and yaw-rate behavior deterministically.
• Wheel state and chassis pose are observable separately; the runtime owns global chassis freedom.
• The package records the pinned OpenArm source and asset licenses.

Non-goals

• Mobile-base inference.
• A detailed contact model for every mecanum roller unless later experiments require it.
• Hardware deployment, which remains a later runtime/profile integration.

Related to #32, #71, #82, and PR #83.