Issue #3616893: Stop the offer stepper tests failing on a loaded runner instead of on a defect

Three tests in OfferStepperTest have gone red intermittently across three issues, and the two earlier ones each fixed the test they named: [#3616605] gave one a diagnostic, [#3616873] pinned what another reads after a submit. The cause is shared, and it is in the tests rather than in the queue they cover.

What the diagnostic said

[#3616605] paid off here. The trace on the last red run reports a perfect setup and no request at all:

busyAtCommit: true, committed: true, valueAtCommit: "2", requests sent after the commit: 0

That is not a lost gesture. It is the queue correctly refusing to dispatch, because Drupal was still working through the answer, for longer than the test was prepared to wait.

Two bets against the runner

A second click hung on a zero-delay timeout inside ajaxSend. A timeout is a task like any other, so a contended runner starves it for longer than the answer takes to arrive and the click lands after the window it belongs in. The lesson is already written into testTheGestureFinishedAfterTheAnswerStillReachesTheServer, which types inside the event for exactly this reason; the two tests that click were left on the timeout, and they are the ones that kept failing. They now click inside the handler too, through one helper that says why.

A fixed wait. A test that holds Drupal busy for four seconds on purpose has spent four seconds of a ten second budget before the queue is even allowed to dispatch, and that hold is itself a timer, so a loaded runner stretches it further. The budget now starts from the window the test opened and adds slack on top.

Where the budget lives

In a new AllowsForALoadedRunner trait, so no test has to remember it, and WaitsForTheNextPage now takes it too: its own ten second default was the same bet, one page load away.

No product code is touched.