Context
We are enabling fast truncate on primaries in disaggregated deployments while standby nodes continue to read from shared stable tables via checkpoint dhandles. In this configuration, fast truncate can leave deleted pages in the shared file that represent truncated key ranges.

Problem
When a standby opens a checkpoint dhandle that includes fast-truncated pages, it may instantiate those deleted pages in memory and then modify them as part of normal cursor, reconciliation, or eviction activity. If those modifications ever flow back through the stable table handle, the standby would violate the core follower-mode invariant that standby nodes must not write to the stable table, and could also resurrect or corrupt truncated data.

This ticket closes that gap by:

1. Reviewing the standby read-path and page-instantiation logic* for fast-truncated / deleted pages loaded from shared checkpoint dhandles, and documenting the expected semantics for how followers should treat those pages (e.g., always logically deleted, never a source of live keys).
2. Adding targeted tests* (e.g., Python replica set / disaggregated tests) that:
   1. perform fast truncates on the primary,
   2. advance the stable checkpoint,
   3. Then drive standby reads and cursor operations across the truncated ranges, to confirm that deleted pages are read back as logically truncated, no keys inside the ranges become visible again, and no writes are issued to the stable table from standby code paths.
3. Updating the standby fast truncate / layered table implementation if needed* so that any per-page or per-btree state changes triggered by reading a fast-truncated page are confined to the layered dhandle or in-memory metadata only, preserving both ASC/primary semantics and the “no writes on stable” guarantee for follower mode.