Conditional polling must preserve pending deliveries and personalized refresh state

Problem/Motivation

Alpha3's conditional refresh can leave a discussion stale after a temporary failure. It records an ETag before delivering the corresponding comments. The next poll can return 304 Not Modified and skip the retry, despite promising that it will retry. Changes deferred beyond the first 50 eligible rows have the same problem.

Two related freshness requirements are also missing: the validator does not distinguish viewer-dependent responses, and unchanged polls stop renewing expiring visit tokens. An account switch can bypass the client's viewer-change check; a long-lived page can submit an expired acknowledgement token.

Steps to reproduce

1. Receive refresh metadata for a new comment, then fail its delivery request once with 503.
2. Leave the server content unchanged and allow the next poll to return 304. The missing comment is not retried.
3. Separately, switch between accounts with the same permissions but different comment ownership. Send the first account's validator as the second account: the endpoint can return 304 although its personalized response differs.
4. Separately, receive a live arrival, then keep the page open beyond the one-hour visit-token lifetime without further changes. Navigate away: the retained token is expired.

The failed-delivery browser probe made two polls but only one delivery attempt. Kernel probes confirmed the cross-viewer validator collision and token expiry; the expiry scenario was not a one-hour browser run.

Proposed resolution

• Track received metadata separately from successfully applied state. Preserve and retry pending work even when the server reports no further content change.
• Make conditional validation respect viewer and access-dependent response changes.
• Renew acknowledgement capabilities while preserving their expiry and bounded, monotonic history semantics.
• Retain the bandwidth benefit for genuinely unchanged, fully applied state.

Remaining tasks

• Test failed delivery followed by recovery without another server mutation.
• Test more than 50 eligible changes and assert every deferred row is eventually applied.
• Test aborted/superseded processing, deferred-arrival retries, and viewer or permission changes without a comment edit.
• Use controlled time to test token renewal across unchanged polls and successful bounded acknowledgement afterward.
• Verify drafts survive these paths and account changes still require a safe reload.

User interface changes

Temporary failures recover, all queued changes appear, and personalized reading state remains valid during long-lived sessions.

API changes

Conditional refresh validation and capability renewal may change. Any response-contract changes must be documented and consumed by the client in the same patch.

Data model changes

None anticipated.