Context
The new standby fast truncate design relies on an in‑memory truncate list attached to the layered table handle to track range truncations without writing metadata to the stable table, so that standby nodes can support fast truncate while preserving the “no writes on stable” invariant. The POC implementation on develop integrates this truncate list with the cursor read path, defining how each cursor operation (e.g., search, search_near, next/prev, random) should consult the truncate list to decide whether keys are visible or truncated.

Problem
However, this cursor–truncate‑list integration has not been systematically reviewed or validated. If the POC behaviour is incorrect or incomplete, standby nodes could:

• Return keys that fall inside committed truncate ranges instead of treating them as deleted
• Skip or hide keys that are outside any visible truncate range
• Loop or perform excessive work when cursors walk through large truncated ranges, especially for next/prev, search_near, and random

Diverge from ASC semantics for mixed truncate/update workloads on the read path, even if write‑side visibility is correct

This ticket closes that gap by validating and correcting the standby fast truncate POC behaviour across the cursor read path: reviewing how each cursor operation interacts with the truncate list, aligning the behaviour with the fast truncate design and ASC semantics, and adding python tests that exercise cursor operations over truncated and non‑truncated ranges so read‑path regressions are caught early and unit tests will validate how truncated ranges are detected and skipped, so read‑path regressions are caught early.