tests: ~20 more fixed-millisecond drain budgets share test_strand_race.cpp's shape (the REQUIRE that aborts before the invariant)

[Yaraslaut]

Summary

morph#374 fixed one fixed-millisecond drain budget in tests/. The same
structural shape — poll a counter for a hard-coded number of 1–10 ms sleeps,
then REQUIRE the counter — is repeated at roughly twenty other sites in
tests/, including two more in the two strand test files themselves. Each is a
statement about how fast the host is, asserted as if it were a statement about
the code.

Filing this as a survey rather than folding it into the #374 fix, per
AGENTS.md. The evidence for the class is a reading of the code; the evidence
that any specific one of these actually expires is weak — see below.

The sites

grep -rn "for (int i = 0; i < [0-9]* &&" tests/ finds, among others:

tests/test_strand.cpp:33:          for (int i = 0; i < 100 && completed.load() < numTasks; ++i)   // 100 x 10 ms
tests/test_strand.cpp:62:          for (int i = 0; i < 50 && completed.load() < numKeys; ++i)     //  50 x 10 ms
tests/test_strand_race.cpp:117:    for (int i = 0; i < 1000 && !ran.load(); ++i)                  // 1000 x 1 ms
tests/test_conflict_resolution.cpp:142
tests/test_client_execute_deadline.cpp:161, 189, 221, 261
tests/test_remote_step_interleaving.cpp:87
tests/test_handler_binding.cpp:57, 73, 139
tests/test_offline_integration.cpp:123
tests/test_switch_backend.cpp:131, 142, 178, 211, 231, 255, 281

Two of these have the exact fix morph#374 used available to them, because they
drain a StrandExecutor or a ThreadPoolExecutor and both destructors are
already exact barriers:

• tests/test_strand.cpp:33 and :62 — ~StrandExecutor blocks until
  _inFlight == 0, which (with posting stopped) means every queued task has
  run. See docs/spec/concurrency_and_lifetimes.md, "The strand model".
  Scoping the strand and dropping the polling loop makes both drains exact.
• tests/test_strand_race.cpp:117 (ThreadPoolExecutor(0) yields a usable pool) — ~ThreadPoolExecutor drains its queue before joining, so closing the
  pool's scope before REQUIRE(ran.load()) removes that budget entirely.

The remaining sites poll for a Completion to settle rather than for an
executor to quiesce, so they have no equivalent barrier and would need a
different treatment (a condition variable, or morph::testing::waitUntil with a
stated budget). They are listed for the record, not because a single fix covers
them.

Verification status

The shape is confirmed by reading. No site in this list was reproduced
failing.

Measured on branch worktree-agent-a7504cb3b48cbffcd (base b219ce51, plus the
morph#374 fix), Linux, clang, linux-everything preset. I probed the two
tests/test_strand.cpp cases the way morph#374's own regression was probed —
pinned to two CPUs on a host already at load average ~85 — and they did not
fail:

$ sh probe.sh   # 10 x: taskset -c 10,11 morph_tests '[strand]~[race]'
test_strand.cpp runs=10 cpus=10,11 failing=0 loadavg=84.83 84.02 78.18

That is a real negative result and it should be read as one: those two budgets
have far more headroom relative to their work (20 tasks x 2 ms against a 1 s
budget; 4 tasks x 30 ms against a 500 ms budget) than morph#374's did
(3200 tasks against a 2 s budget), which is exactly why #374's expired and these
did not. For contrast, under the identical pinning the pre-fix
test_strand_race.cpp failed 5 runs out of 5:

run 1: FAILED rc=42 43s
tests/test_strand_race.cpp:71: FAILED:
with expansion:
  201 == 3200 (0xc80)
test cases: 1 | 1 failed
assertions: 1 | 1 failed

Not verified:

• Whether any of these has ever fired in CI. I did not audit CI history.
• The 17 non-strand sites. I did not run them under load at all; they are here
  because they share the shape, not because they were measured.

Why it is worth recording anyway

morph#374's cost was not that it flaked — it was that the drain REQUIRE came
before the invariant REQUIRE, so Catch2 aborted the case and the invariant
was never evaluated. Note assertions: 1 | 1 failed in the output above: one
assertion ran, out of the 40 that case contains. Every site in the list has the
same ordering, so each carries the same latent "the check you cared about never
ran, and the report names it anyway" failure mode. Whether the budget is
comfortable today is a separate question from whether the report would be
truthful if it were not.

What would change the verdict

• Close it if the two test_strand.cpp drains and the
  ThreadPoolExecutor(0) drain are converted to their executors' destructor
  barriers, and the remaining sites are either given a stated budget with the
  deficit in the message or judged individually and left with a written reason.
• Close it as invalid if someone shows these budgets are load-independent —
  they are literal iteration counts of fixed sleeps, so that would require
  showing the work they wait on is bounded by something other than the host.
• Escalate it if any of these is seen failing in CI, which would move it
  from "shape" to "reproduced".

[Yaraslaut]

Triaged: triage: valid.

Re-verified the survey against current origin/master, independently of the
issue's own branch/commit:

• Re-ran the issue's own grep (for (int i = 0; i < [0-9]* &&) against
  tests/: 25 matching sites today (issue said "roughly twenty" — in the
  right ballpark; some line numbers have drifted, e.g.
  test_strand_race.cpp:117 is now :127, consistent with normal file churn
  since filing, not a misreading of the shape).
• Confirmed test_strand_race.cpp's originally-flagged case (the
  maxInFlight/kExpected one) already carries the test_strand_race.cpp's drain deadline can fail under load, reading as a strand-serialisation failure #374 fix on master: a
  CHECK for the drain count with an INFO deficit message, REQUIRE only on
  the maxInFlight == 1 invariant, exactly as 873ff82b ("tests: drain the
  strand race by destructor, not by deadline") describes.
• Confirmed the second site in the same file — ThreadPoolExecutor(0) yields a usable pool (line ~119-130) — still has the pre-test_strand_race.cpp's drain deadline can fail under load, reading as a strand-serialisation failure #374 shape
  untouched: a fixed for (i < 1000 && !ran.load()) 1ms-sleep loop immediately
  followed by REQUIRE(ran.load()). This is exactly the "two more in the two
  strand test files themselves" the issue calls out, and it is real, present,
  unfixed.
• Read ~ThreadPoolExecutor() (include/morph/core/executor.hpp:66-82) and
  ~StrandExecutor() (include/morph/core/strand.hpp, _cv.wait(lock, [this] { return _inFlight == 0; })): both destructors are exact drain barriers,
  confirming the issue's claim that test_strand.cpp:33/:62 and
  test_strand_race.cpp's ThreadPoolExecutor(0) case can drop their polling
  loops entirely in favor of scoping — the same fix 873ff82b already applied
  once.
• Spot-checked one of the 17 "different treatment" sites,
  test_client_execute_deadline.cpp:161: it polls a Completion/callback
  settling via exec.runFor(), no executor destructor to lean on — confirms
  the issue's own classification that these need morph::testing::waitUntil
  or similar rather than the destructor trick. (waitUntil is an existing,
  widely-used primitive in tests/test_support.hpp, used in 39 files — not a
  new ask.) Also noticed this site has the identical REQUIRE-before-CHECK
  ordering hazard the issue is about, one call further down
  (REQUIRE(failed) before CHECK(threwClientTimeout)) — consistent with,
  not contradicting, the issue's claim that the shape recurs broadly.
• Did not re-run the taskset-pinned load experiment myself (Windows/clang-cl
  here vs. the issue's Linux measurement, and the point of that experiment —
  showing a negative result honestly — doesn't need re-doing to be trusted;
  it's a straightforward loop-count/timing argument, not a surprising claim).

This is an unusually well-calibrated issue: it separates "confirmed by reading"
from "confirmed by reproduction" throughout, reports a negative result
(test_strand.cpp not failing under load) instead of suppressing it, and gives
concrete close/escalate conditions. Nothing found here contradicts any part of
it. area: core already applied; adding triage: valid since the direction
(destructor-barrier for the two strand-file sites, waitUntil/stated-budget
treatment for the rest, decided case-by-case) matches the architecture and
needs no rewrite before someone implements it.