Background

WT-18717 root-caused a real bug in src/cursor/cur_layered.c: layered-cursor iteration assumes only the ingest cursor can stop on a prepared conflict (WT_CURSTD_KEY_INT cleared but a btree page reference retained), and every helper that reasons about walk position (_clayered_any_constituent_positioned, clayered_ingest_prepare_blocked, clayered_select_current) bakes in that assumption. A prepared update on the stable constituent breaks it and trips an assert in _clayered_select_current.

This is confirmed to be a defect in develop itself, not something introduced by WT-18422. Two blanket asserts currently make it unreachable through any supported configuration:

• __wt_txn_prepare (src/txn/txn.c) aborts the process the instant any transaction tries to prepare while the step-down timestamp is set, regardless of when that transaction began.
• __session_commit_transaction (src/session/session_api.c) aborts the process if a prepared transaction commits while the step-down timestamp is set.

With both asserts removed on a plain develop checkout (no WT-18422 code present), the following reproduces the __clayered_select_current assertion failure directly:

1. Write stable content, then prepare an update on a middle key while the leader is outside any step-down window (routed to stable alone).
2. Announce the step-down timestamp.
3. Write unrelated, already-committed keys straight to ingest on either side of the blocked key (mirroring off).
4. Walk with a reader: hits WT_PREPARE_CONFLICT on the blocked key as expected.
5. Roll back the prepared transaction to clear the conflict, then call next() again to resume the walk.

Step 5 aborts: __clayered_select_current, 1873: WiredTiger assertion failed: ... __clayered_ingest_prepare_blocked(op, c_current).

Ask

Add a temporary, diagnostic-only feature flag (or debug config knob, following the pattern of similar temporary test-enablement flags elsewhere in the connection config) that allows prepared transactions to proceed while the step-down timestamp is set, bypassing the two asserts above only when the flag is set. This is deliberately narrow: it must not change default behavior, and should be clearly marked for removal once the layered-iteration fix (WT-18717) is verified and merged.

Purpose: this lets WT-18717's fix (generalizing the prepare-blocked check to either constituent — patch ready, see the ticket) be verified and merged against develop directly, independent of and ahead of WT-18422, using test/format and a Python regression test gated behind the new flag. WT-18422 already needs to remove both asserts permanently as part of its own work; once it lands, this flag becomes redundant and should be deleted along with the asserts it wraps.

Relates to

• WT-18717 (the iteration bug this flag makes testable on develop)
• WT-18422 (the eventual permanent removal of both asserts)