Context
The ASC fast truncate implementation cannot run on standby nodes because it writes fast‑truncate metadata directly to the stable table, violating the core invariant that standby mode must not perform updates/inserts on the stable table. To enable fast truncate on standbys while preserving this invariant, the new design inserts a truncate layer between the ingest and stable tables, so the read/write path becomes: ingest → truncate → stable.

Problem
During step‑up, WiredTiger must drain data from the ingest table into the stable table and also apply any outstanding truncates so that the new primary’s stable table reflects all committed updates and truncates. In the current POC, the step‑up path does not yet implement a complete fast truncate ingest drain: truncates are replayed on the ingest table, but there is no validated mechanism to ensure all relevant truncates are correctly applied to the stable table during the drain.

Without a correct fast truncate ingest drain on step‑up, the new primary will:

• Leave keys on the stable table that should have been truncated according to the ingest/truncate state, or
• Over‑truncate keys on the stable table if we mis‑replay truncate ranges relative to drained updates
  Either case can cause the stepped‑up primary’s stable table to diverge from the correct fast truncate semantics and cause data inconsistencies.

This ticket closes that gap by implementing and validating the fast truncate ingest drain on step‑up: ensuring that all relevant truncates are correctly drained from ingest/truncate state onto the stable table following the fast truncate design, and adding Python tests that exercise mixed update/truncate workloads across step‑up so that drain‑related regressions are caught early.