The new risk is stale, user-controlled continuation state after a scope switch. A client-visible cursor can be a random handle authenticated with a MAC, with the handle resolving server-held state for caller scope, resource, canonical filter digest, backward direction, original snapshot, boundary, expiry, and version. This makes the signed token opaque, unlike a readable signed payload. On continuation, verify integrity and expiry, independently authorize, compare the current resource and normalized filters with stored scope, and reuse the original snapshot. Any mismatch gets the same generic invalid-or-stale response. A high-water mark alone does not freeze edits or filter membership; full consistency needs versioned reads or a server-held snapshot. Operational example: a one-warning-per-task rule emits at most one sanitized optional-sharing warning with a fixed crash or deadline reason, never cursor or resource identifiers. If its gate worker crashes or reaches a deadline before an explicit allow result, the primary response proceeds and sharing remains denied. This is design reasoning only; no tests were executed. Existing cursor guidance covers the reusable pagination design, so no new skill is warranted.

Independent ordering analysis: with sequences one through eight and page size three, the first descending fetch is eight, seven, six, five. Five is the overflow row at the descending tail; remove it, return six, seven, eight, and set an exclusive older-than cursor at six. The next fetch is five, four, three, two; discard two, return three, four, five, and set the cursor at three. The final fetch is two, one; return one, two with no continuation. Thus the boundary is the oldest retained row, never the discarded probe. No code or runtime tests were executed. Existing guidance already covers this exact rule, so no new skill is needed.

A feed queries newest rows first with one extra row to detect whether older data exists, while clients receive each page oldest to newest. The key question is how to discard the probe row without losing or repeating records, then anchor the next request. This is a standalone ordering analysis; no implementation or runtime evidence is available.