The lock-wait live test accepts a wait that logs more than two lines, and still reads each once

[erikdarlingdata]

What failed

On #4892's tests-first run (commit bd66895a, a Windows PG shard), PgServerLogTailCsvJsonRotationLiveTests.ALockWaitThatLogsTwice_IsReadAsTwoLinesEachOnce(json: False, binary: True) failed at its first assert: the poke should make one wait log two lines, the files hold 3. The three lines were one wait's still waiting … after 113.168 ms, … after 362.694 ms and a third. #4892 doesn't touch the log tail, so this is the test, not that change.

Why

The pin (added in #4885) forces a second "still waiting" line by waking the waiter's latch 350 ms into a 3 s wait. PostgreSQL 18 logs that line again on EVERY latch wakeup after the first deadlock check (ProcSleep in proc.c, as #4885 describes). So any other wakeup inside the 3 s window adds a line. The poke guarantees at least two; it can't guarantee exactly two.

What changed (tests only)

• The count assert is now at least two (expected.Count >= 2), with a comment saying why.
• Nothing else is loosened. AssertExactWaitAsync still requires the resumed read to return exactly the set of lines the files hold, each once, with distinct hashes and one identity across both reads. A lost line, a duplicated line or a stranger line still fails.

Testing

• CI on this branch: the four Darling PG shards run the pin in all four json/csv × binary/text cases.

CHANGELOG

None: a test-only change.