kanban: test_kanban_stress.cpp's own waitUntil uses hand-picked 20s/90s budgets, not MORPH_LADDER_DEADLINE_MS-scaled

[Yaraslaut]

What

examples/kanban/tests/test_kanban_stress.cpp's own waitUntil(pred, budget, step) helper (lines 139-150) polls with hand-picked fixed wall-clock budgets
that are not scaled by MORPH_LADDER_DEADLINE_MS, unlike every
pumpUntil-based wait in the ladder testkit:

template <typename Pred>
[[nodiscard]] bool waitUntil(Pred pred, std::chrono::milliseconds budget = std::chrono::milliseconds{20000},
                              std::chrono::milliseconds step = std::chrono::milliseconds{5}) {
    const auto deadline = std::chrono::steady_clock::now() + budget;
    while (!pred()) {
        if (std::chrono::steady_clock::now() >= deadline) {
            return false;
        }
        std::this_thread::sleep_for(step);
    }
    return true;
}

Call sites use the 20000ms default six times, plus one explicit 90000ms
budget (line 395) for a 32-way concurrent-drag/ThreadSanitizer stress case
over a real ThreadPoolExecutor{4}.

This is the same shape #223 flagged in test_ledger_reports.cpp
(pollUntilSettled, now fixed): a real, deliberate wall-clock poll against a
genuine thread pool (justified — this file's own header comment explains why
DeterministicExecutor isn't wireable here and a real pool is needed for the
ThreadSanitizer coverage), but with a fixed, hand-picked budget instead of one
scaled by MORPH_LADDER_DEADLINE_MS the way examples/common/testkit/ pump.hpp's pumpUntil/deadlineScale() scales every other ladder wait.

Found while triaging #223; not covered by that issue's grep (for (int i = 0; i < 100) since this helper uses a deadline-based loop, not a fixed iteration
count, and #223 never mentions this file.

Why it matters

Under a slow/loaded CI runner or a sanitizer build (exactly the case
MORPH_LADDER_DEADLINE_MS exists to compensate for — see pump.hpp's own
doc comment: "scales every pumpUntil default deadline uniformly (slow CI
runners, sanitizer builds)"), this file's fixed 20s/90s budgets don't grow
with the rest of the suite's polls, while every pumpUntil-based wait in the
same CI run does. This file is explicitly a ThreadSanitizer target
(file header: "run under ThreadSanitizer in CI"), which is exactly the
condition MORPH_LADDER_DEADLINE_MS scaling was introduced to cover.

Proposed fix

Once #223's corrected scope lands (a non-Qt waitUntil(pred, deadline)
helper sharing pump.hpp's MORPH_LADDER_DEADLINE_MS scale factor), point
this file's local waitUntil at it instead of hand-rolling its own
un-scaled version — one instance of invariant 6 (a guarantee reimplemented
per call site belongs in one place) rather than two now separately
un-scaled implementations.

This issue should stay blocked/deferred until #223 lands, since it's the
same helper this local one should delegate to.

[Yaraslaut]

Triage: premise confirmed, but verdict is parked not valid

Premise checked empirically

examples/kanban/tests/test_kanban_stress.cpp's waitUntil (lines 139-150)
is exactly as quoted — a hand-rolled steady_clock-based poll, not routed
through pump.hpp. Call-site count is off by one in the issue: there are
7 call sites using the 20000ms default (lines 220, 238, 259, 269, 279,
293, 409 — not six), plus the one explicit 90000ms budget at line 395. None
scaled by MORPH_LADDER_DEADLINE_MS.

Confirmed this is the same class of gap as #223: a deliberate, justified,
real-ThreadPoolExecutor retry loop (the file's own header comment explains
why DeterministicExecutor isn't wireable here, and examples/TESTING.md
line 235 sanctions exactly this pattern — "a test that keeps a real
ThreadPoolExecutor under an async job... says so at the test case and pays
the retry loop knowingly" — though TESTING.md's own text only names
test_ledger_reports.cpp there, not this file; a second real instance of the
same sanctioned pattern, not a new kind of thing). Not a false analogy.

One correction to the issue's framing: the 90000ms budget at line 395 is
not actually hand-picked the way #223's original 100x10ms budget was —
lines 385-394 carry a measured justification ("this exact 200-action
workload... finished in ~32s under real TSan instrumentation in CI,
comfortably inside 90s"). The defect isn't an unjustified number; it's that
even a justified fixed number has no dial for a slower runner or a future
TSan version with more overhead, unlike every pumpUntil-based wait, which
is the actual point MORPH_LADDER_DEADLINE_MS scaling exists for. Doesn't
change the verdict, just sharpens the "why".

Checked: could this call pump.hpp's deadlineScale() directly, right now?

No, and not merely as a style preference. Two independent reasons:

1. deadlineScale()/computeDeadlineScale() live in morph::ladder:: testkit::detail — an explicit internal seam (see pump.hpp's own doc
   comment on computeDeadlineScale), not a published cross-file API.
2. pump.hpp unconditionally #includes <QCoreApplication> and
   <QEventLoop> at file scope. test_kanban_stress.cpp's ~90-line header
   comment is not incidental Qt-avoidance — it's the direct fix for morph#128,
   where this file's previous Qt-routed version produced 165 ThreadSanitizer
   warnings that were unusable as evidence specifically because they bottomed
   out in an uninstrumented, prebuilt Qt build. Pulling in pump.hpp to reuse
   one pure function would reintroduce a Qt header into the file whose entire
   documented purpose is "zero Qt frames anywhere in the call graph" — the
   precise class of dependency invariant 2 warns against imposing on a
   consumer that has deliberately structured itself to not need it.

(Aside: ladder_kanban_tests as a binary already links Qt6::Core
unconditionally via testkit_main.cpp, per cmake/morph_add_rung.cmake.
That means Qt is already in the executable regardless — but the invariant
this file maintains is about its own translation unit's include graph and
call graph, verifiable per-file, which is a stronger and more useful
guarantee than "Qt happens to be linked somewhere in the binary".)

So the fix genuinely cannot be pulled forward independent of #223: there is
no non-Qt shared helper to point at yet, and hand-building one inside this
file would pre-empt #223's own still-open design question ("whether this
helper belongs inside pump.hpp itself... or beside it... is a design call
for whoever picks this up").

Verdict: triage: parked, not triage: valid

Per the skill's valid-vs-rescope test: triage: valid means "implement as
written." This issue cannot be implemented as written today — its own
proposed fix is "point this file's waitUntil at [#223's helper]," and that
helper does not exist (#223, now triage: valid, is itself only a corrected
scope, not a landed PR — no commit or PR implementing it exists on
master as of this comment). Building a substitute now would duplicate
work #223 hasn't finished deciding the shape of, which is the same
rule-of-three-adjacent risk invariant 6 warns about, just pointed the other
direction (pre-empting the single shared place rather than multiplying
copies of it).

This matches the shape of #87 ("Fold examples/bank into ladder conventions
— blocked on #86"), already labeled triage: parked for exactly this
"real problem, correct direction, explicitly blocked on a sibling issue's
unbuilt helper" reason.

Re-entry condition: once #223's non-Qt waitUntil(pred, deadline) helper
(sharing pump.hpp's MORPH_LADDER_DEADLINE_MS scale factor) lands, revisit
this issue and point test_kanban_stress.cpp's local waitUntil at it,
removing the duplicate implementation. If, when #223 lands, its helper turns
out unsuitable for this file's needs for some reason not anticipated here,
that would be new information changing this verdict — flag it against this
issue rather than assuming the delegation is mechanical.

Labels applied: triage: parked, area: ladder.

[Yaraslaut]

Unblocking this — #223 is being closed as stale, so the helper it promised is not coming from there.

This issue records that it "should stay blocked/deferred until #223 lands, since it's the same helper this local one should delegate to." That condition can no longer be satisfied as written.

#223's call site was deleted rather than fixed: pollUntilSettled no longer exists anywhere in examples/ (git grep pollUntilSettled -- examples returns nothing), because #160/#243 made the report aggregation an ordinary synchronous action. examples/ledger/tests/test_ledger_reports.cpp now states outright that there is no loop, no sleep and no cap any more.

So #223's first half (remove the poll) is satisfied, but its second half — a non-Qt waitUntil(pred, deadline) helper sharing pump.hpp's MORPH_LADDER_DEADLINE_MS scale factor — was never built, and this issue is now its only consumer. That obligation moves here.

examples/kanban/tests/test_kanban_stress.cpp is now the only fixed-wall-clock test poll left in examples/: budget = 20000ms default at :137 with sleep_for at :144, seven call sites, plus an explicit 90000ms at :394.

Constraint to carry over: this file must stay Qt-free (see its header comment re: morph#128), so the shared helper must not drag pump.hpp's <QCoreApplication> in with it.

Re-entry condition replaced: not blocked — ready to pick up.