Issue Summary

Prepared truncate is not supported when the connection is configured with preserve_prepared=true. Nothing enforces this today, so a prepared truncate under that config would silently reach code paths that cannot handle it. Add an assertion so this misuse fails immediately instead of producing incorrect state.

Context

• Rolling back a prepared fast-truncate still discards the page-deleted structure unconditionally; __wt_delete_page_rollback in src/btree/bt_delete.c carries a TODO noting prepared rollback is not handled there.
• Under preserve_prepared, prepared updates are written to disk with their prepare state and must be rollback-able after reconciliation. Truncate operations (WT_TXN_OP_REF_DELETE, WT_TXN_OP_TRUNCATE_ROW, WT_TXN_OP_TRUNCATE_COL) do not follow that model.
• No current check rejects or asserts on this combination in __wt_txn_prepare (src/txn/txn.c).

Proposed Solution

• In __wt_txn_prepare, when WT_CONN_PRESERVE_PREPARED is set, assert that no transaction op is WT_TXN_OP_REF_DELETE, WT_TXN_OP_TRUNCATE_ROW or WT_TXN_OP_TRUNCATE_COL.
• Decide whether this should be a diagnostic-only WT_ASSERT or a release-mode WT_ASSERT_ALWAYS / ENOTSUP return.
• Make sure test/format and the Python suite do not issue truncate inside prepared transactions when preserve_prepared is on (or that they are adjusted accordingly).

Definition of Done

• Assertion added and exercised; existing CI (including format runs with preserve_prepared=1) is green.