Two related bugs in the follower fast truncate cursor path.

Bug 1: search_near + next() returns a truncated stable key

After search_near returns an ingest key, the first next() lazily positions the stable cursor via __clayered_position_alternate. That function does not consult the truncate list, so it can land on a stable key inside a committed truncate range and return it to the caller.

Repro: stable [0,10,20,30], ingest [5], truncate [8,12] — search_near(5) + next() incorrectly returns key 10.

Fix: __clayered_position_alternate must call __clayered_reposition_truncate_iterate after positioning the alternate stable cursor.

Bug 2: Tombstone stamped on out-of-range ingest key when cursors cross

When a truncate range contains no ingest keys but ingest keys exist on both sides, __clayered_position_near_key leaves ingest_start (forward) positioned past ingest_stop (backward). The do-while in __clayered_range_truncate_ingest executes its body before checking cmp, tombstoning the out-of-range key that ingest_start landed on.

Repro: stable [0,5,10,15,20], ingest [5,15], truncate [8,12] — key 15 (outside range) is incorrectly tombstoned and becomes invisible.

Fix: Add a crossed-cursor check before entering the do-while in __clayered_range_truncate_ingest.