Background

A schema operation enqueues a shared metadata entry that captures the table's local metadata at enqueue time, including the stable constituent's configuration (btree id, checkpoint information). The snapshot is written to the shared metadata table when a later checkpoint drains the entry. The only refresh happens at step-up, and only for entries whose captured value is empty (__layered_create_missing_stable_tables_helper), which covers creates made on a follower.

Problem

With schema epochs the queue survives a step-down, so an entry can outlive the leader era that captured its value, and nothing brings the captured value up to date. A step-up / step-down / step-up sequence then drains a snapshot from a dead era:

1. Era N (leader): create table X. The queue entry captures era-N metadata. The entry is never covered by an era-N checkpoint (unpublished, or published above every covered epoch), so it survives the step-down.
2. Era N+1 (follower): the peer leader also creates and covers X, and checkpoint pickups rewrite the local metadata for X (new btree id). The queue prune cannot remove the surviving entry - an unpublished entry carries the maximum epoch - and nothing updates its captured value.
3. Era N+2 (leader again): the step-up refresh skips the entry because its captured value is non-empty. When the entry is eventually published and covered, the drain writes the era-N snapshot into shared metadata: a stale btree id and stale checkpoint information for a tree that era N+1 recreated.

A reader following the stale id fails to find the tree's pages. This is the same failure family as the stale-btree-id problems tracked by FIXME-WT-17746.

There is no reproducer yet. One needs a step-up / step-down / step-up workflow where the peer leader covers the same table in between, in the style of the layered async step-down tests.