fix(ui): refresh the start page on a settings change, and write every duration one way

[PurpleSentinel]

Closes #152.

Two defects on the same screen, found on the device within minutes of each other.

1. The start page kept the values it read at boot

Rest was changed to ten seconds. The rest timer ran for ten seconds; the start page went on
reading 20 MIN REST until a restart. The device displayed one thing and did another, on
the value a driver is most likely to check before going out.

refresh_ready() is the only thing that rebuilds the dashboard, and it was called from
exactly two places:

Call site	When
build()	once, at boot
apply_selected_track()	when a track is chosen

Nothing called it when a setting was committed — neither the roller nor the value carousel.
ready_snapshot() reads the durations from settings_ correctly; it was simply never asked
again.

The timing side was unaffected, which is why the ten second rest was honoured:
SessionConfiguration is built from settings_ at session start, not from anything the
dashboard holds.

Fixed in persist_settings(), which every settings change already goes through, so the next
screen that writes a setting cannot forget it. Unconditional rather than only on a successful
save: if the save fails, settings_ still holds what the device will use for the next
session, and that is what the driver should see.

2. Durations were written two ways at once

format_duration_value printed whole minutes as 20 MIN and anything carrying seconds as
20:30, so the page read 1 MIN SESSION beside 0:12 REST.

The inconsistency dates from when the formatter was written, but was invisible until
durations could hold seconds at all — only possible since the roller replaced the preset
ladders. The moment a rest period could be twelve seconds, the two formats sat side by side.

One format everywhere now: 20:00, 1:00, 0:12, 90:00. This also changes the settings
editor, which formats through the same function — that is the point, one way of writing a
time across the device rather than one per screen.

How both got through

35 host suites and 70 simulator tests pass, and passed throughout.

• The stale dashboard is a missing call in ScreenRouter, which has no host test harness
  at all, so nothing exercises "a setting was committed" → "the dashboard was redrawn".
• The format split is only visible when two durations are rendered together, and every
  test asserts its own format in isolation.

This is the third defect of the first shape recently: #142 had rest modelled and tested but
never routed to a screen, and #144 had the vehicle frame correct in every host test while the
axis reaching the display was inverted. The logic keeps being right; the wiring to the panel
keeps being what nothing checks. Making ScreenRouter testable off-device would catch all
three — noted on #152 rather than attempted here.

Verification

35 host suites, 70 simulator tests, and confirmed on the physical panel: a changed rest
duration is now reflected on the start page before the next session, and session and rest are
written the same way.