Summary

A disaggregated checkpoint on a newly stepped-up leader panics with EINVAL "Stable data checkpointed for unpublished table" for a table that was created, published, and populated while the node was a follower.

Root cause

On step-up, the shared metadata queue is rebuilt using a code path chosen by whether the follower ever picked up a leader checkpoint that carried a schema epoch. A follower that creates and publishes tables before picking up any such checkpoint has last_ckpt_disaggregated_schema_epoch == 0, which causes step-up to take the legacy rebuild path. That path clears the queue and re-enqueues all CREATEs with the unpublished sentinel epoch (WT_TS_MAX), discarding the real epoch that was published on the follower. The next leader checkpoint sees data for a table whose CREATE entry is still marked unpublished and panics.

The fix is to take the legacy path only when the queue is also empty, since a non-empty queue means schema epochs are in use regardless of whether a leader checkpoint has been picked up.

How to reproduce

On a fresh follower that has not picked up any prior leader checkpoint, create and publish a table, insert data, then step up and checkpoint. Reproduced by test/csuite/schema_disagg_abort whenever the child starts as a follower. test/suite/test_layered_schema10.py does not hit this because every test there seeds a leader checkpoint first, giving the follower a non-zero epoch baseline before step-up.

Expected

Step-up preserves the schema epoch published on the follower so the subsequent checkpoint flushes the table's CREATE and data at a consistent epoch without panicking.