Summary: Cursor writes on a follower can be resolved before the isolation check, so read-committed and read-uncommitted writes do not return ENOTSUP

Problem

Writes at read-committed or read-uncommitted isolation are rejected with ENOTSUP by __wt_txn_id_check, which sits at the bottom of the write path. On a local table nothing can resolve a write before that check is reached. On a follower the layered cursor layer sits above it and can finish the operation first, so the documented usage error is not what the caller sees.

Measured on a follower, with an uncommitted truncate covering the key:

• Read-committed insert and update: the truncate-list search runs first and calls a visibility helper that requires a snapshot the transaction has not taken. This asserts in a diagnostic build.
• Read-committed remove: WT_ROLLBACK (retryable) instead of ENOTSUP (usage error).
• Read-uncommitted remove: the lookup that precedes the write treats the uncommitted truncate as visible, concludes the key is already deleted and returns WT_NOTFOUND. No error is raised and the transaction continues.

modify and reserve are unaffected today because neither consults the truncate list, but neither has any check above the btree layer either.

The equivalent gap on the follower truncate path is fixed by WT-18786, which checks the isolation level before recording a truncate-list entry. That fix is scoped to truncate and does not cover the cursor write paths.

Definition of Done

• A follower cursor write at read-committed or read-uncommitted returns ENOTSUP, matching a local table and the follower truncate path.
• Python test covering insert, update, remove and modify at both isolation levels on a follower, with and without an overlapping uncommitted truncate.