fix(firmware): halt-on-failure stopped waiting for the wave to finish (v0.24.5-beta)

A regression I introduced in v0.24.3, and described inaccurately in its own
commit message.

Adding concurrency moved the halt check to the end of a wave. I wrote that
"at the default of 1 those are the same moment". That is only true of a wave
holding one device. With several devices in one wave and the default
sequential setting, the old code stopped the moment one failed; mine went on
to attempt every remaining device in that wave first. Anyone relying on
halt-on-failure with a wide wave 1 got a wider blast radius than before,
without changing a setting.

Halting now stops further devices from *starting* as soon as a failure is
known, whatever the concurrency. Devices already in flight are allowed to
finish, because interrupting one mid-write is how you brick it. At
concurrency 1 that is precisely the previous behaviour. Above 1, only the
devices genuinely running side by side can carry a bad build -- which is the
unavoidable part of the trade in #135, rather than a cost imposed on rollouts
that never asked for concurrency.

The firmware documentation said the same wrong thing and is corrected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/firmware.md

@@ -55,10 +55,11 @@ everything after it.
 
 There are two costs, and both are worth understanding before you raise it.
 
-**Halting becomes less precise.** With one device at a time, a failure stops the
-rollout immediately. Running several at once, the wave finishes first — so a wave of
-five can put a bad build on five devices before anything stops. At the default of 1
-these are the same moment.
+**Halting becomes less precise.** A failure stops any further device from *starting*,
+immediately — but devices already running finish, because interrupting one mid-write is
+how you brick it. So with **At once** set to five, up to five devices can carry a bad
+build before anything stops. At the default of 1 nothing else has started, so a failure
+stops the rollout exactly as it always has.
 
 **Devices reboot together.** That is fine for independent routers. It is not fine for
 a switch that the others are reached *through*: rebooting it alongside them cuts the