A Java-source watcher test times out under load instead of waiting for the event it needs

One occurrence, during a verification build on a machine also running two other Maven reactors. 125 tests in graphitron-maven-plugin, one failure:

An immediate mvn test -pl :graphitron-maven-plugin -Dtest=CatalogRefreshTest on the same tree ran 3/3 green, which is what makes this a timing fault rather than a defect in the watcher.

The failure mode is indistinguishable from the real regression the test exists to catch: "the refresher did not fire". A reader of a red build cannot tell a loaded machine from a broken dispatch without rerunning, and the natural reflex on a timing-shaped failure is to raise the budget, which weakens the pin permanently in exchange for one green build.

The two sibling cases in the same class share the pattern, so whatever the fix is, it applies to all three rather than to the one that happened to lose the race.

Not designed yet. The shape to look for is a wait that ends when the condition is decidable rather than when a clock expires: the latch already exists, so the question is whether the budget can come from the debounce interval it is actually racing (a multiple of DEBOUNCE_MS) instead of a flat constant, and whether the failure message can distinguish "no event arrived" from "the event arrived after the budget" by checking the latch once more after the store assertion.

Worth checking first whether the wider suite has a shared idiom for this. If several tiers wait on filesystem or debounce events with hand-rolled latches, the fix is one helper, not a patch per call site.