A follower is supposed to read the stable tree only at its last picked-up checkpoint, through a URI with a "/<checkpoint name>" suffix. The cursor path (_clayered_open_stable_follower), the history store cursor, the statistics cursor, and prepared discovery all follow that convention, but the layered verify worker (_schema_layered_stable_worker_verify) passes the plain stable URI down regardless of role, so a follower's verify opens the live stable handle instead of the pinned checkpoint.

Today this is masked because the btree open resets the runtime write generation for every disaggregated tree on a follower by role, which clears the leader's transaction ids on any handle the verify opens. If the reset is keyed on the handle itself (WT-17763 moved it to the pinned-checkpoint name form), the follower's verify reads the leader's raw transaction ids as its own current ones and the internal-page aggregate validation fails (__time_aggregate_validate_parent: child carries a raw id above an obsolete-cleared parent aggregate), as seen in format disagg-switch data-validation runs.

Fix: make the follower's layered verify look up the last picked-up checkpoint name and verify through the suffixed URI, retrying when a concurrent pickup supersedes the checkpoint (the open returns EBUSY), matching the cursor path.