Problem

The layered cursor notices that its read context changed by comparing the session's WT_GEN_HAS_SNAPSHOT generation (plus the read timestamp and the transaction's modification count). When nothing changed it trusts the alternate constituent's parked position instead of repositioning it.

The generation only advances when a transaction with writes commits. Prepare also makes updates visible to new snapshots (it removes the transaction ID from the global table), but did not advance it. A new snapshot that sees a prepared update therefore carries the same generation as one that did not.

Impact

A positioned follower walk can return stale data instead of WT_PREPARE_CONFLICT:

1. A follower walk in a snapshot transaction is on stable key 340, with ingest parked on 600.
2. Another session prepares a remove of key 350. The generation does not change.
3. The walk's transaction (read-only) commits. The generation does not change.
4. The walk continues under autocommit and takes a new snapshot that sees the prepare. Same generation, so ingest is not repositioned.
5. Stable steps to 350 and returns its old value. A btree cursor would hit a prepare conflict on 350.

Fix

Start a new snapshot generation in __wt_txn_prepare, as commit does, so cached snapshots and positions are refreshed.

Known gap

The generation is still bumped after the updates become visible, so a snapshot taken in that window can share a generation with an earlier one. Tracked separately in WT-18966.