The racy agent row has a cause: a busy machine, not a wrong compiler

FIX.org

@@ -2634,13 +2634,17 @@ what was true when they were written.
   fixed it (~trap_park stops dying on the abort race~), so the green run is a
   real green run rather than a lucky one.
 
-  One *other* ~test_dev.ml~ row failed once across five runs of identical
+  One *other* ~test_dev.ml~ row failed twice across seven runs of identical
   code — "the merged program never bound ...agent.sock", a daemon that did not
-  come up in time — and was green on the four runs either side of it, on the
-  lane and in the merged tree. Recorded rather than chased: it is a socket
-  bind in the agent fixture, and this lane touches neither the agent nor the
-  dyn side. It looks like the same family as the ~trap_park~ race that was
-  just fixed, one row further along.
+  come up in time — and was green on every run either side, on the lane and in
+  the merged tree. The second failure named its own cause: the corpus sweep was
+  compiling in another worktree on the same machine, and the row gives the
+  daemon a fixed window to bind in. Run on an idle machine it is green.
+  Recorded rather than chased: it is a socket bind in the agent fixture, this
+  lane touches neither the agent nor the dyn side, and it looks like the same
+  family as the ~trap_park~ race that was just fixed, one row further along —
+  a timeout that is generous when nothing else is running and is not
+  otherwise.
 - test/programs/widening.flan, new, with three acceptance rows — default, -O0
   and ~--x86~ — and its output diffed by hand across the two backends before
   the rows were written. Byte-identical.