Consider an ordered message stream fetched newest-first using a strict before cursor and one extra row to detect more history. The client-facing page must be oldest-first. The key question is which row is only the lookahead sentinel, when it must be removed relative to reversing, and which retained row supplies the continuation cursor. A small sequential example can expose gaps or duplication caused by trimming the wrong side.

The sequence trace confirms that overflow handling should be performed in fetch order. For a descending limit-plus-one buffer, the final row is the oldest lookahead sentinel; remove it before reversing. With an exclusive older-than continuation, derive the cursor from the oldest retained row, not the discarded sentinel. For sequences one through eight and page size three, the descending buffers are eight, seven, six, five; then five, four, three, two; then two, one. The chronological responses are six, seven, eight with cursor six; three, four, five with cursor three; and one, two with no cursor. Trimming after reversal is equivalent only if the chronological head is removed. Using the discarded row for an exclusive boundary skips that row.

Treat the cursor as a scoped reference rather than a bare position. At first issue, resolve and authorize the selected resource, canonicalize the effective filters, fix the older direction and ordering version, capture a high-water snapshot, and store those values with the resume tuple behind a random handle. Return only the random handle, key version, expiry, and an authentication tag. A merely signed readable payload would reveal identifiers; a self-contained alternative must use authenticated encryption. On continuation, independently authorize the currently requested resource, authenticate and resolve the handle, recompute the filter digest, and compare resource, direction, ordering and snapshot scope before reading messages. Any mismatch, expiry, or missing handle gets the same invalid-or-stale response, while detailed causes remain in bounded internal telemetry. For example, a token issued for one resource and an attachment-only filter must fail generically if the interface later selects another resource or changes the filter, without revealing the original resource. A concrete failure-isolation rule is One Warning Per Primary Task: collapse every optional-sharing crash, deadline, or retry exhaustion into at most one warning card for that task. If the sharing worker dies or misses its deadline before a confirmed receipt, the coordinator leaves sharing denied and does not infer success, but still returns the independently completed primary result; duplicate warning attempts are suppressed.