Problem

A layered table held locally without its stable constituent — e.g. a follower that applied a mirrored drop and recreate of the same URI — picks up a checkpoint cut before the drop's REMOVE drained. The shared metadata still carries the previous incarnation, and pickup adopts its stale file: entry under the recreated table.

Impact

The table opens the dropped incarnation's btree: stable reads return the old table's data under the new name, and the next pickup halts on the btree ID change (checkpoint pickup metadata mismatch ... "id" differs). Every two-node schema_disagg_abort mode currently aborts on this within seconds.

Root cause

The both-have-layered: branch of __disagg_apply_checkpoint_meta (src/conn/conn_layered_checkpoint_pick_up.c) adopts the shared file: entry whenever the local one is missing, without the queue-vs-checkpoint-epoch check its table-absent-locally neighbour already performs. Distinct from the pure-follower drop-path gap (WT-18068/WT-17746): here the local metadata was correct and the pickup itself re-introduces the stale entry.

Reproduction and fix

test_layered_schema28.py: deterministic, fails unfixed, passes fixed. Fix: skip adopting the stable component when the table's latest queued create sits above the checkpoint's schema epoch; a later checkpoint that covers the create supplies the right constituent.