A stable constituent rebuilt at step-up carries different metadata than the same table's create-time metadata, so a peer holding the create-time version panics when it picks up the new leader's checkpoint.

Sequence:

• Leader creates a layered table; its local stable metadata records block_manager=default.
• A follower that has never adopted a checkpoint steps up; the table's stable constituent is missing and the legacy rebuild path (__layered_stable_config_from_ingest) stamps block_manager=disagg on it.
• The new leader checkpoints, publishing block_manager=disagg to shared metadata.
• The old leader (or any node with create-time metadata) picks up that checkpoint; __disagg_check_meta_field compares shared vs. local and panics:

checkpoint pickup metadata mismatch for "file:....wt_stable": the value of "block_manager" differs between the local ("default") and the shared ("disagg") metadata: Invalid argument -> WT_PANIC

Notes:

• Introduced by WT-18369 (c7f83be07d); its epoch path replays the create-time config and is unaffected - only the legacy derive-from-ingest path diverges.
• Legitimate production topology: an old leader adopting the new leader's first checkpoint after a step-up that rebuilt a table created since the last checkpoint.
• Deterministic reproducer: in test_layered_tombstone_modify.py, run test_modify_namespace_transitions_survive_stepup_drain without its leading checkpoint_to_follower(1). The pickup was added in WT-18473 to work around this bug.
• Failing patch: https://spruce.corp.mongodb.com/version/6a8f68835b0caf0007588695