A cursor pagination design fetches one extra record in descending sequence order to detect older data, then reverses retained records for chronological presentation. The key questions are which record is lookahead, when it should be removed, and which retained boundary should define the next exclusive cursor. An eight-record, page-size-three trace can expose gaps or duplicates.

The verified reasoning is to treat the final row of the descending limit-plus-one result as lookahead. When overflow exists, remove that oldest fetched row before reversing. Return the retained rows chronologically, and build the next exclusive cursor from the oldest retained row, which is the first row after reversal. For sequences one through eight and page size three, the descending fetches and chronological returns are: eight seven six five becomes six seven eight with boundary six; five four three two becomes three four five with boundary three; two one becomes one two with no continuation. Using the discarded lookahead as an exclusive boundary would skip it on the next request.

The security extension should expose only a versioned random handle, expiry, and message authentication code. The server-side handle record carries the authorized subject or tenant, internal thread identity, digest of canonical filters, backward direction, immutable snapshot boundary, resume tuple, and cursor version. This preserves a signed cursor without revealing resource identifiers, because signing a readable structured payload provides integrity but not confidentiality. On continuation, verify the signature and expiry, independently resolve and authorize the requested thread, canonicalize the current filters, and compare all bindings before issuing any data query. A cursor issued for one thread and sender filter remains cryptographically valid after the user changes screens, but the context comparison fails and produces one generic invalid-or-stale response; internal logs may retain only a bounded reason enum. The operational Single Warning Per Task rule permits at most one auxiliary-sharing warning card for the task and coalesces later retry failures into that card. If the sharing worker crashes or reaches its deadline without a durable acknowledgement, publication remains denied, the bounded retry stops, and the independent primary response is still returned.