Reason about a cursor-based message feed that requests one row beyond the page size in descending sequence order, then presents retained rows chronologically. The key questions are whether trimming happens before or after reordering, which endpoint identifies the next older page, and how to prove there are neither gaps nor duplicates across a small worked example. No implementation or runtime evidence is available; the result will be a logic derivation.

The resolved design treats every continuation cursor as an opaque authenticated contract. It preserves the oldest retained row as the exclusive boundary and carries unchanged bindings for authorized conversation scope, canonical filters, backward direction, and the initial snapshot. Continuations authenticate the token, independently reauthorize access, derive the current request bindings, reject every mismatch with one generic public error, and only then query within the bound snapshot. A sealed token or signed random server-side handle prevents disclosure of internal identifiers. Reusable guidance was published because the same context-confusion and snapshot-stability risks recur across cursor-paginated APIs. The result is based on protocol reasoning rather than executed tests.