Problem

When preserve_prepared is enabled, prepared transactions must survive a crash and be recoverable with their original timestamps intact. The roundup_timestamps connection-level configuration modifies timestamps at the time they are applied — rounding a commit or durable timestamp up to the current oldest or stable timestamp to avoid ordering violations.

These two features are semantically incompatible: roundup_timestamps can silently alter the prepared transaction's timestamps, producing a different on-disk state than what the application intended. After a crash and restart with preserve_prepared, the engine will attempt to recover prepared transactions using potentially-rounded timestamps that the application never explicitly set, which can cause:

• Timestamp ordering invariants to be violated on recovery
• Prepared transaction state to be unrecoverable or incorrect
• Silent data corruption in MVCC history

Proposed Fix

Add a validation check (either at connection open time or when a prepared transaction first sets a timestamp) that returns WT_EINVAL if both roundup_timestamps (for the prepare or commit sub-options) and preserve_prepared are active simultaneously.

The check should be placed in the timestamp-setting path (_wt_txn_set_timestamp or the connection config validation in _wt_conn_config_init) with a clear error message explaining the incompatibility.

Acceptance Criteria

• Opening a connection with both roundup_timestamps and preserve_prepared enabled produces a WT_EINVAL error with an informative message, OR setting a prepared timestamp on a session where both are in effect produces WT_EINVAL.
• Existing tests for preserve_prepared and roundup_timestamps individually continue to pass.
• A new test (Python suite or csuite) covers the disallowed combination.
• Public API documentation (api_data.py or config comment) is updated to note the restriction.