test(system): a response wait only where it is the evidence

[ExtraToast]

Closes #1125.

Why

Two flakes in two runs, on branches that touch neither the frontend nor the code under test:

EventPageSystemTest > logged-in user can delete existing event sign-up() FAILED
    com.microsoft.playwright.TimeoutError: Timeout 5000ms exceeded

RecoveryManagerPageSystemTest > board deletes user from member manager and restores in recovery manager() FAILED
    com.microsoft.playwright.TimeoutError: Timeout 5000ms exceeded

Both wrapped a click in page.waitForResponse and then asserted the real outcome on the very next line — the sign-up gone from the database, the account back in the pane. The wait was a weaker second copy of that assertion, and it is the copy that fails: it caps the round trip at the shared five-second budget, on the browser's view of a request whose success re-renders the element the click was on.

What this achieves

The rule is written down and the suite follows it. 19 of the 62 call sites were duplicates and go; the assertion that follows each one is unchanged and now gets the full budget instead of what the wait left it.

How

The rule lives in Polling.kt, beside the budget every wait already shares, because that is the file a test reads when it is choosing how to wait.

A wait earns its place when the response is the evidence — EventPageSystemTest reads an x-guest-access-token header, ActivationPageSystemTest reads an error body, EventEditPageSystemTest asserts the banner is fetched at its own public address and nothing observable follows. It also earns it when something touches the page before the assertion does: a navigation, another pane opened, a second form filled. There the wait is what stops the request racing whatever comes next.

It does not earn it when the assertion is the next thing. Those 19 became a plain click followed by the pollFor or Playwright assertion that was always the real check.

Worth a reviewer's attention

The sweep exposed one real race rather than causing it. The membership rendezvous writes the membership row and the MEMBER role separately; confirming the address after applying starts the membership polled for the row and then asserted the role without polling, and the response wait had been padding the gap. Removing the wait turned that into Expecting ["GUEST"] to contain ["MEMBER"]. The poll now waits for both facts, which is what the scenario is named for.

I tightened the rule twice while applying it, because the first two passes were wrong in ways only running the suite showed: a variable read more than once is a response being asserted, and an interaction between the click and the assertion means the wait is synchronising. Both are in the written rule now.

Verification

./gradlew :tests:system:test against a compose stack on the CI images, every class the sweep touched — EventPageSystemTest, EventSignUpsPageSystemTest, ActivationPageSystemTest, AddressPageSystemTest, CommitteeManagerPageSystemTest, JobManagerPageSystemTest, RecoveryManagerPageSystemTest, MembershipSignUpPageSystemTest — 37 tests, 37 passed.

An earlier, looser version of the sweep failed two of those tests, which is how the two extra conditions were found. The full six-shard suite runs here in CI.

---

Diff breakdown — █ added ░ removed, scaled to the largest row.

system-tests                                       +44   -142    7
  system tests       ██████░░░░░░░░░░░░░░░░░░░░    +44   -142    7

──────────────────────────────────────────────────────────────────
production                                          +0     -0
tests                                              +44   -142
total (hand-written)                               +44   -142  7 files