We need derive the ordering invariant for backward pagination. A data source fetches one extra row in newest-first order, while the API returns retained rows oldest-first. The key questions are which end contains the overflow record before reversal, which retained record defines the next cursor, and how the sequence behaves across a small worked example.

Reasoning: add a five-code, one-warning rule at the cursor-validation boundary. Each request may emit at most one warning, and its reason must be one of authenticationfailed, contextchanged, snapshotunavailable, authorizationchanged, or malformedtoken. The only permitted dimensions are endpoint and service version; thread, filter, position, subject, cursor bytes, and decrypted values are forbidden as labels or message text. For example, a stale backward token issued for one conversation is presented after the UI selects another conversation. The protected bindings disagree, so the API returns the same generic invalid-cursor result used for every validation failure and records only contextchanged. If a separate sharing worker then crashes or reaches its deadline, the API response and pagination state machine still complete because sharing is outside the primary correctness path. Sharing remains denied and unpublished unless the worker receives a positive durable acknowledgement; timeout or process loss must never be interpreted as permission to disclose, and a later recovery must reconcile the original idempotent operation before attempting replacement. Executed tests: none. This is a standalone operational reasoning result, and no files or machine state were inspected or changed.