Flaky live test: ALogThatGrewPastTheWindow times out with 0 rows read on unrelated PR runs #4719

PgServerLogTailRotationLiveTests.ALogThatGrewPastTheWindow_DisclosesTheBytesSkipped_AndCollectsTheLastWindow fails on pull request runs that don't touch the stderr log tail. It then passes when the same job is re-run.

Failures

• 2026-09-29 05:27Z, PR PostgreSQL 13 csvlog records (24 columns) are parsed instead of rejected, and rejected records are counted (#4709) #4714 (csv parser only), Darling PG tests (1): "the lock-wait entry for pid 10660 never reached the log file read (9439257|postgresql-2026-09-29_052714.log) after 51 attempts over 30 s; 0 rows read, bytes skipped 5329924". The re-run at 05:45Z passed.
• 2026-09-29 05:27Z, PR RDS PostgreSQL log reads: finish rotated files in one cycle, keep positions across a restart, report skipped and missing files (#4708) #4713 (RDS log source only), Darling PG tests (1): the same message, with bytes skipped 5330183.
• Dev at cdc8d7d (04:21Z) passed all three PG shards.

The test is stderr-only (log_destination = 'stderr'), and neither PR changes PgServerLogTail.cs or the stderr assembler. #4707 added the 30-second wait (CycleUntilLoggedAsync) that is timing out here.

What is known

• After a 6.5 MB RAISE LOG burst, the test provokes one lock-wait entry and repeats the same read (the same carried state) for 30 seconds. The read covers the last 4 MB of the file and finds no rows at all, so the entry is either not in that window or not written.
• The rotation classes share the pg-log-rotation collection with parallelization disabled, so another class in that collection can't write during this test.

Leads (not verified)

• Another writer lands after the entry and pushes it out of the last 4 MB window. Check whether the CI target for DARLING_TEST_PG_LOGROTATE also serves tests outside the pg-log-rotation collection, which would write to the same server log in parallel.
• The entry is never written. The waiter uses lock_timeout = '800ms', so the "still waiting" line depends on the target's deadlock_timeout firing first.
• The logging collector has not written the entry within 30 seconds after the burst.

Expected

• Make the failure message explain itself: the newest file in the log directory, its size, and the last few lines of the file the read used.
• Find the cause and fix it there. A longer timeout alone is not a fix.
• The change is test-only unless the cause is in the tail itself.