After a switchover or failover, the WAL archive (S3/object storage) still contains segments from previous timelines. When a replica restarts with existing PVC data (e.g. after a rolling restart triggered by parameter change), its restore_command can fetch old-timeline WAL segments from the archive before streaming replication reconnects to the new primary.

This causes the replica's timeline history to diverge from the current primary, resulting in either:

CrashLoopBackOff:

LOG: restored log file "00000002.history" from archive
LOG: restored log file "00000003.history" from archive
LOG: restored log file "00000001000000000000004B" from archive   ← timeline 1!
LOG: restored log file "000000010000000000000048" from archive   ← timeline 1!
LOG: entering standby mode
FATAL: requested timeline 3 is not a child of this server's history
LOG: startup process (PID 34) exited with exit code 1
LOG: database system is shut down

Stuck in "Standby (file based)" mode:

LOG: restored log file "0000000100000032000000E8" from archive   ← timeline 1!
LOG: invalid record length at 32/E80000A0: expected at least 24, got 0
LOG: fetching timeline history file for timeline 2 from primary server
FATAL: could not receive timeline history file from the primary server: ERROR:
  could not open file "pg_wal/00000002.history": No such file or directory
LOG: waiting for WAL to become available at 32/E80000B8

Root cause

validateTimelineHistoryFile() in walrestore/cmd.go validates .history files but does not check regular WAL segments. A replica can successfully download 000000010000000000000048 (timeline 1) from the archive when the primary is already on timeline 3.

Fix

Added validateWALSegmentTimeline() which rejects WAL segments whose timeline is older than the cluster's current timeline, for replica instances in established clusters. This forces PostgreSQL to fall back to streaming replication from the current primary instead of consuming stale WAL from the archive.

The check is skipped when CurrentPrimary is not set (during bootstrap or PITR recovery) to allow fetching WAL from any timeline.

Reproduction

Minimal reproducer using kind + MinIO: reproduce.sh

1. Create a 3-instance cluster with synchronous replication and WAL archiving to MinIO
2. Write data, take backup, write more data
3. Change shared_buffers to trigger a rolling restart with switchover
4. Replica restarts with existing PVC, restore_command fetches old-timeline WAL from MinIO
5. Replica crashes or gets stuck in file-based mode

In the provided test environment (kind, single-node, local MinIO, synchronous replication), the bug reproduces consistently. In multi-node production clusters the issue is intermittent, depending on the timing between switchover completion and replica reconnection.

Without the fix: replica enters CrashLoopBackOff or Standby (file based).
With the fix: old WAL is rejected with warning log, replica uses streaming replication:

WARNING: Refusing to restore old-timeline WAL segment for replica
  walName=000000010000000000000048 walTimeline=1 clusterTimeline=3

Testing

• Unit tests added for validateWALSegmentTimeline covering all branches
• Verified recovery from S3 backup works correctly (PITR not broken)
• Verified rolling restarts with switchover work without file-based or CrashLoop

Closes #4990
Related: #4188, #3344