Say S17 clears once the new bus is sent, as it does

The comment and the signals table's bound said it cleared once the bus's machine runs the new build; it
clears once that machine has been sent it, when no send is refused for the bus any more.

cmd/mesh-controller/bus_waits.go

@@ -19,8 +19,9 @@ import (
 // as the walk's note; nothing was raised, and the operator found the hold by asking why a walk did not move.
 // Row S17 raises it on the first tick after the first refusal, in the bus's scope, for the operator: what
 // waits, behind which bus build, since when, and the verb. A walk held only by it is not late, so S3 leaves it
-// out, as it leaves out a walk under a paused build seat. It clears once the bus's machine runs the build the
-// mesh holds — the step was taken — whatever the walks' notes still say.
+// out, as it leaves out a walk under a paused build seat. It clears once the bus's machine has been sent the
+// build the mesh holds — the step was taken, and no send is refused for the bus any more — whatever the walks'
+// notes still say. Whether the new bus came up healthy is the step's own condition (probe DB).
 
 // kindBusStepWaiting is S17's kind: bus.<module>.step-waiting.
 const kindBusStepWaiting = "bus-step-waiting"