test: fix flaky LogicalReplicationStatusTest by polling pg_stat_replication - #3974

…cation

The tests were flaky because they assumed forceUpdateStatus() is
synchronous — that pg_stat_replication immediately reflects the sent
values. In reality forceUpdateStatus() only flushes data to the TCP
socket; the server needs time to process the standby status update.

During receiveMessageWithoutBlock(), readInternal() may trigger an
automatic timeUpdateStatus(). The server processes it and shows that
value in pg_stat_replication. When forceUpdateStatus() sends a newer
value moments later, the test queries the view before the server has
processed the second update, seeing the stale value.

Fix: add an optional expected parameter to getLSNFromView(). When
non-null, it polls until pg_stat_replication matches the expected
value (with a 2-second timeout). All tests that call
forceUpdateStatus() followed by a view query now pass the expected
LSN, eliminating the timing race.

Also replace getBackendPID() + string-concatenated pid filter with
a PreparedStatement that joins pg_replication_slots on slot_name,
keeping the PID lookup entirely on the server side.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>