fix(settings): put the launch ladder inside what a car can actually pull

[PurpleSentinel]

Closes #156.

The scale was mostly decorative

The IMU trigger reads forward acceleration, which a car reaches at roughly 0.3 to 1.0 g.
The ladder ran:

0, 0.50, 1.00, 1.25, 1.50, 1.75, 2.00, 2.50, 3.50, 4.00   (g)

Six of ten choices could never fire, and nothing was offered below 0.5 g, where a
deliberate pit exit actually sits. The setting was stored and editable but read by nothing
until #155 wired the trigger, so the values had never been checked against a measurement.

New ladder: 0.15, 0.20, 0.25, 0.30, 0.35, 0.40, 0.50, 0.60, 0.80, 1.00, default 0.30 g.

Zero is gone

It meant "off", which as a trigger threshold is a device that never starts a session. TRIGGER
is the on/off now, so the threshold is always a real value and MANUAL is how you decline it.

Stored settings are snapped, not rejected

This is the part that matters. valid_launch_sensitivity whitelists exact values, so a stored
2.50 g under the new rules would fail validation — and validation is on the whole blob,
so the device would fall back to defaults and lose every unrelated setting with it. A
threshold moving one step is a far better outcome than losing the session duration, the
selected circuit and the trigger.

nearest_launch_sensitivity maps every old value onto the new ladder. Zero maps to the
default, not the nearest — nearest would be 0.15 g, the most trigger-happy setting of all,
which is a poor thing to hand someone who had it switched off.

One definition instead of three

The ladder lived in the picker, the stepping editor and the validator. Three copies is how
it drifted away from anything measurable without anyone noticing. There is one now, and the
editor's test reads it rather than restating it — so a test can no longer describe a ladder
the device does not offer, which is exactly what the old test was doing.

Verification

36 host suites and 70 simulator tests. The snapping is covered directly: every old ladder value
lands on a valid new one, values above the top land on the top, nearest is checked either side,
values already on the ladder are untouched, and the ladder's own bounds are asserted against
what a car can pull.

On the device, settings written by the previous firmware migrated in place and the selected
circuit gb_croft_full was still restored afterwards — a non-default value that a reset to
defaults would have lost.

An honest gap in the tests

I could not build an end-to-end test that decodes a v6 blob holding an out-of-range launch
value, because every encoder validates before writing, so such a blob cannot be constructed
through the public API. The snapping is therefore unit-tested at the function and confirmed on
real stored settings on the panel, rather than driven through decode_settings. That the
encoders refuse to produce one is itself reassuring, but it does leave the seam untested.