Fix go() not moving the robot: use DRIVE_DIRECT instead of radius DRIVE

[fedenanni]

No description provided.

[LyngeLauritsen]

Summary

All motion convenience commands (turn, spin, forward, back, move) and scripts/drive_until_bump.sh (which calls go <speed> 0) route through protocol::go(). That function emitted the radius-based DRIVE command (opcode 137) — drive(velocity, radius) with radius ±1 for in-place turns and 0x8000 for straight.

On this robot, opcode 137 is not reliably honored: the wheels stayed at idle (motor current never rose above baseline) while the daemon still returned OK turn 90deg (~1.5s). So the robot reported success and the heading map updated, but it never actually moved — it "thought" it was rotating/driving while sitting still.

Fix

Reimplemented protocol::go() using DRIVE_DIRECT (opcode 145, independent wheel velocities), which drives the motors reliably:

• straight: drive_direct(v, v)
• CCW (+deg): drive_direct(+wheel, -wheel)
• CW (−deg): drive_direct(-wheel, +wheel)

The wheel-speed ↔ angular-rate calibration (WHEEL_SPAN_MM) is unchanged, so existing turn/spin/move durations still produce the intended angles and distances. Updated the three affected unit tests.

Testing

• cargo test — all 29 pass.
• Verified on hardware: rebuilt + restarted the daemon; before/after camera frames confirm turn now produces a real rotation in both CW and CCW directions (previously the view barely moved). This also restores forward driving used by the escape loop.

Note: the running daemon must be restarted to pick up the rebuilt binary.