Fix: calibrated scales keep their size, and snap in the unit they were written in

[Sherin-SEF-AI]

Defects

1. Small scales became zero. Scales were rounded to six decimal places, so a field in 1e-7 degrees (a common GPS encoding) came back with scale 0.0, and the DBC layer reads a zero scale as 1. Scales and offsets now keep seven significant figures. The new test fails on the old code.
2. Snapping ignored units. A GPS logger reports m/s; a car's DBC says 0.01 km/h per bit, which is 0.0027778 m/s. No round number in m/s matches that, so it never snapped. Given the reference's unit, snap_calibration now also tries km/h, mph and knots (degrees for radians, psi and bar for kPa), under the same bias gate, and candidate_to_signal_def writes the signal in the unit the manufacturer used, noting the reference unit in its description.

A real-data check the calibrator lacked

phase_reference in acceptance_new_sources.py fetches comma.ai's comma2k19 example segment (MIT, about 6 MB): one minute of a Toyota RAV4's CAN bus with a u-blox receiver, and openpilot's DBC as the answer key. From the GNSS speed alone:

Check	Result
Speed signals found	0x0B4 bytes 5-6 (vehicle speed) and all four 0x0AA wheel words, R² 0.998
Wheel scale as written	0.01 km/h per bit, offset -67.05 to -67.19; openpilot says 0.01 and -67.67
UTC reference onto the capture's clock	within 0.168 s of the true offset
That residual	the receiver's latency: 0.14 s measured by the search, 0.16 s by a cross-correlation of openpilot's own speed against GNSS that does not use CanLab
The written signal	decodes the car within 0.87% of openpilot's decode

The vehicle-speed field does not snap to 0.01 km/h, correctly: this car's speed signal reads about 0.8% above GPS, and forcing the round scale would move the decode past the 1% bias budget.

pytest -q: 726 passed. phase_reference: 4/4. ruff clean.