Background

Under schema epochs, a table created on a leader but never published keeps its state local: the stable constituent exists and may hold data, the shared metadata queue holds an unpublished CREATE carrying a snapshot of the table's metadata, and no checkpoint advertises any of it. Unpublished entries carry the maximum schema epoch, so the queue prune can never remove them, and they survive step-down.

Problem

Everything about such a table is frozen in the leader era that created it, while the rest of the cluster moves on. After a step-down, a peer leader that replayed the same create can publish and cover its own copy of the table, giving it a different stable btree and checkpoint history in shared metadata. When the original node later steps up, it still holds:

• a queued unpublished CREATE whose captured metadata snapshot describes the dead era's constituent (the step-up refresh only repairs entries with no captured value),
• a local stable constituent whose content was never published anywhere and may now diverge from the incarnation the cluster adopted in between,
• local metadata that checkpoint pickups partially rewrote during the follower phase, so the queue snapshot, the local metadata and the shared metadata can each describe a different tree.

Publishing and draining the surviving CREATE at that point writes the dead era's description into shared metadata over the incarnation the cluster is actually using, and readers of the shared metadata can end up chasing a tree that no longer exists. This is the same failure family as the stale-btree-id problems tracked by FIXME-WT-17746; WT-18310 covers the narrower stale-snapshot case, and the step-down assertions from WT-18276 check window creates but deliberately exempt unpublished pre-window creates, which are legal at step-down.

There is no reproducer yet. One needs a table created and left unpublished on a leader, a step-down, a peer era that publishes its own copy of the table, and a step-up followed by publishing the survivor.