Problem

__checkpoint_disagg_publish (src/checkpoint/checkpoint_txn.c) decides whether an awaiting-publish disaggregated btree is published for a checkpoint by scanning the shared metadata queue for the table's latest create/remove. The scan is O per awaiting-publish btree per checkpoint.

Optimization

Cache the published create epoch on WT_BTREE (create_schema_epoch, set at publish time) so the checkpoint decision is an O(1) field read instead of a queue scan.

Why it needs care

The field must be set on the correct stable-constituent btree at publish. A fresh create cannot set it at open, because the CREATE queue entry does not exist yet. A missed set means the table never publishes and eventually panics. So the change must set the field on every publish path (leader, follower step-up, reopen) and guard against a missed set: when the field is unset but the queue shows a real published create, panic rather than silently skip.

Why deferred

The correctness fix (WT-18093) uses the always-correct queue scan. This optimization trades that for cached state with a coherence obligation, for a modest win on a rarely hot path, so it is scoped as a separate change.