drv/geometry: give the robot dimensions one home, measured on a v3

[geonnave]

The dimensions were in three places and all three disagreed

drv/move/move.c and drv/control_loop/control_loop.c each carried their own
copy of the wheel diameter, gear ratio, encoder resolution and track, and
PyDotBot's simulator carries a third in Python. The two C copies agreed with
each other and both were wrong; the simulator was closer.

Bench measurements on a v3 settle all three open numbers:

	measured	was in the C drivers
wheel diameter	44 mm (caliper)	40 mm
track, wheel mid-plane to mid-plane	77 mm (caliper)	90 mm
encoder counts per wheel revolution	1400	600

Track is carried as 78 rather than the raw 77 so the C and Python models
agree exactly. The encoder figure comes from 01bsp_qdec with the robot pushed
by hand through one wheel turn, twice: 1399/1401 and 1408/1392, both runs
averaging 1400.0, all four readings within 1.14%. That is 28 counts per motor
shaft revolution over the 50:1 reduction, which is a 7 PPR encoder decoded x4.
The nearest alternatives are 15% away, so nothing else fits. An earlier hand-turn
reading of about 14300 counts per wheel revolution is superseded: it corresponds
to roughly ten wheel revolutions rather than one.

Net effect on behaviour: every odometric distance drops to 43% of what the
firmware previously computed, and the heading integration was under-rotating by
14% from the track alone. Nothing that consumes odometry was correct before this.

Why the header is under drv/ and not in bsp/conf/

These values are per-board, so bsp/conf/dotbot_v3_config.h is the obvious
home, and it does not work. control_loop.c is also compiled on the host for
PyDotBot's simulator, and that build puts only drv/ on the include path;
reaching bsp/conf/ means going through board_config.h, which pulls in
gpio.h and the nRF headers. The header therefore keys off the same
BOARD_DOTBOT_V* macros but stays free of hardware dependencies. There is a
comment saying so, because moving it is the natural thing to try.

v1 and v2 are deliberately unchanged

Only a v3 was measured. v1 and v2 keep 40 mm, 90 mm and 12 CPR in the #else
branch, because applying a v3 caliper reading to boards nobody put a caliper on
would be an assertion rather than a measurement.

Also here

control_loop_get_geometry() exports the compiled constants so a host holding
its own copy can check the two against each other. PyDotBot has a test that uses
it; that test skips against a library predating this change, so the two can land
in either order.

Validation

Host build with BUILD_WITH_EKF=ON links clean. SES BUILD_TARGET=dotbot-v3 make 01drv_move links clean under -Werror -Wall -Wextra. Values were checked
by compiling and printing them per board rather than reading the source: v3 gives
44 / 78 / 28 / 50 and 0.098736 mm per count, v1 and v2 give 40 / 90 / 12 / 50 and
0.209440. clang-format -style=file clean.

Not validated on a moving robot. What stays unproven is the encoder count at
speed: a hand push is slow, so it cannot show sample-rate loss, and
db_qdec_init leaves SAMPLEPER at its 128 us reset default, which at 28 CPR
gives roughly 20x margin at full motor speed. The signature if that is wrong is
driven odometry reading consistently short of 10128 counts per metre.

[geonnave]

Superseded by #28, which carries these three commits unchanged plus the sensor lever arm, the geometry getter and a motor brake. Closing so there is one branch to review.