The flake note said noise; the full-suite numbers say otherwise

Isolated test_dev is 4-in-6 here against 2-in-6 at the base, which is noise.
The full suite is 5-in-5 here against 0-in-5 at the base, which is not — and
with this lane's three acceptance rows disabled it drops to 1-in-3. The rows
add compile jobs to the pool test_dev runs alongside, and a busier machine
loses the trap_park poll race more often.

Still not a new defect, and none of this lane's compiler code is implicated.
But the earlier note's suggested fix is now worth doing rather than noting,
and saying 'noise' would have sent the next reader the wrong way.

FIX.org

@@ -1784,18 +1784,36 @@ reason, since review found the tagged types were sharing a line that was
 false for two of them — both arities, both no-expected-type positions, the
 byte's range, the pattern's range and the ~defconst~ rule.
 
-~dune test~ exits 1 on this branch roughly half the time, with *no FAIL line
+~dune test~ exits 1 on this branch about half the time, with *no FAIL line
 anywhere* — the ~Flan.Wire.Closed~ flake an earlier lane wrote up further up
-this file. Measured rather than assumed, because 2-of-2 early failures looked
-like mine: running ~test_dev.exe~ alone (15 seconds, not the ten-minute
-suite) gives 4 failures in 6 on this branch and *2 in 6 on a detached
-worktree at this branch's own base commit*, 1526b6f, with none of this lane
-in it. Same exception, same mechanism, and the difference is noise at that
-sample size.
+this file. Green runs are real (2 of the last 4 exit 0); the rest are that
+race.
 
-One detail worth adding to that earlier writeup, which said both observed
-failures landed on ~dev-trap-null-alloc~: it is not row-specific. Five of my
-six failures were that row and the sixth was ~dev-trap-free-all~, so what is
-racy is ~trap_park~ itself and every row that calls it, which is what the
-mechanism described there would predict. Per the sweep policy the ~@x86~ and
+*This lane makes it fire more often, and that is worth saying plainly rather
+than filing the whole thing under "known flake".* Measured, because early
+runs looked like the lane had broken something:
+
+| what                                  | full ~dune test~ |
+| base commit 1526b6f, none of the lane | 0 failures in 5  |
+| this lane                             | 5 failures in 5  |
+| this lane, my 3 acceptance rows off   | 1 failure in 3   |
+
+Isolated, ~test_dev.exe~ alone (15 seconds, not the ten-minute suite) gives 4
+in 6 here against 2 in 6 at the base — much closer, which is the shape you
+would expect if the lane is not touching the racy code but *is* changing the
+load around it. The three acceptance rows add three compile-and-run jobs to
+the pool that ~test_dev~ runs alongside, and a busier machine is slower to
+answer the poll that races.
+
+So: not a new defect, and nothing in ~check.ml~/~emit.ml~/~x86.ml~ here is
+implicated — but the next lane to add acceptance rows will push the rate up
+again, and the fix the earlier writeup already named (catch ~Closed~ in
+~trap_park~'s poll and read it as the program having ended) is now worth
+doing rather than noting.
+
+One detail to add to that earlier writeup, which had only seen the flake on
+~dev-trap-null-alloc~: it is not row-specific. Five of my six isolated
+failures were that row and the sixth was ~dev-trap-free-all~, so what is racy
+is ~trap_park~ itself and every row that calls it — which is exactly what the
+mechanism described there predicts. Per the sweep policy the ~@x86~ and
 ~@sanitize~ sweeps were not run here.