Goal

During async step-down every commit after the cutoff must carry a commit timestamp strictly greater than the cutoff, so that all new transactions land cleanly above the boundary and post-step-up replay is well ordered. Today an untimestamped commit succeeds while step_down_timestamp is set: __txn_validate_commit_timestamp (src/txn/txn_timestamp.c) only runs when the transaction supplies a commit timestamp, so a bare commit_transaction() skips the check and is routed to the ingest constituent.

The goal: no untimestamped write commit succeeds on a disaggregated connection while the step-down timestamp is set.

Evidence

• test/suite/test_layered_async_stepdown05.py:153 test_untimestamped_commit_while_step_down_ts_set pins the current (wrong) behavior: begin, write, commit with no commit-timestamp while the cutoff is set succeeds and lands in ingest. The test comment says "this pins current behavior".
• Timestamped commits at or below the cutoff are already rejected with EINVAL (src/txn/txn_timestamp.c, commit-ts validation), and test_commit_at_or_below_cutoff_rejected asserts that refusal — only the no-timestamp path is unchecked.

Possible approaches (assignee decides)

• EINVAL in the commit path when a disagg connection has the step-down timestamp set, the transaction has modifications, and no commit timestamp was supplied.
• Or a diagnostic-only assert if the server can already guarantee it never does this.

Either way, test_untimestamped_commit_while_step_down_ts_set must be rewritten to assert the refusal (mirroring test_commit_at_or_below_cutoff_rejected).

Context

Found during a review of the async step-down contract (WT-17895 lineage) against the Python step-down suite and test/format.