Summary: Follower fast truncate skips the commit-timestamp check and leaves an untimestamped truncate-list entry

Problem

• WT_TXN_OP_FOLLOWER_TRUNCATE is resolved by __wti_mark_committed_truncate_table, not __wt_txn_op_set_timestamp, so __txn_disagg_commit_ts_check never runs for a truncate whose range has no ingest key.
• A commit without a commit timestamp stores an entry with start_ts = durable_ts = WT_TS_NONE.
• __layered_table_truncate_gc never collects entries with durable_ts == WT_TS_NONE.
• At step-up __layered_apply_truncate_to_stable asserts start_ts > WT_TS_NONE (diagnostic); release replays the range with timestamp 0.

Scenario

• Follower: begin_transaction, truncate a range of stable-only keys, commit_transaction with no commit_timestamp.
• Leader and per-key remove: rejected with EINVAL once debug_mode.disagg_commit_ts_optional is off.

Definition of Done

• Follower truncate commit runs the same commit-timestamp check as other disaggregated writes.
• Python test: untimestamped follower truncate fails at commit with the check enforced.
• Python test (knob on): step-up with an untimestamped entry does not assert.