Description:

The fast-truncate POC lets callers truncate from a start key to the end of the table by passing a NULL stop cursor. Internally this "no stop" state is preserved throughout the lifetime of the truncate entry, which forces every code path that reads the truncate list to handle it as a special case.

This creates two problems:

1. Correctness surface. Open-ended ranges have no upper bound, so they also cover keys that don't yet exist — rows appended after a truncate commits can still be hidden by it. The scan and search paths currently disagree on this behavior, and the semantically correct answer (appended rows should remain visible) is harder to reason about while the "no stop" state exists.

1. Code and test burden. Every consumer of the truncate list — visibility checks, iteration, conflict detection, future features — must branch on the open-ended case. Every test matrix has to cover it as a distinct scenario. The special case leaks into the design instead of staying at the API boundary.

Proposal:

When a truncate commits with no stop cursor, resolve "end of table" to a concrete key once and store it as the stop key on the truncate entry. From that point on, every truncate range in the system is bounded. The read path, the filters, and the tests can all assume a uniform shape.

This is done internally to the fast-truncate work — it doesn't change the public session.truncate() API.