Fix repeated WAL scans during subscription catch-up

[Caideyipi]

Description

Reuse the WAL iterator during historical catch-up

A bounded consensus-subscription prefetch round recreated ProgressWALIterator at nextExpectedSearchIndex before reading each batch. The iterator still opens retained WAL files from the beginning and applies startSearchIndex only after request deserialization, so every batch repeatedly scanned all earlier WAL entries. The resulting read amplification grew with catch-up progress and made consumption progressively slower.

This change keeps the existing iterator, including its WAL reader cursor and buffered look-ahead request, across normal bounded prefetch rounds. Explicit resets remain in place for seek, WAL-gap recovery, exhausted live WAL refresh, and memory rollback.

Regression coverage

A real sealed-WAL test limits each batch to one entry and verifies that three consecutive catch-up rounds:

• reuse the same ProgressWALIterator;
• advance the read search index contiguously;
• deliver writer local sequences 1, 2, and 3 exactly once.

Verification

mvn -o test -pl iotdb-core/datanode -am -Dtest=ProgressWALIteratorTest,ConsensusPrefetchingQueueTest,ConsensusPrefetchingQueueWalBackpressureTest -Dsurefire.failIfNoSpecifiedTests=false -DfailIfNoTests=false

Tests run: 29, Failures: 0, Errors: 0, Skipped: 0.

This PR has:

• been self-reviewed.
• added comments explaining the why and intent of the code.
• added unit tests covering the regression.

Key changed/added classes

• ConsensusPrefetchingQueue
• ConsensusPrefetchingQueueWalBackpressureTest