Build infinite scroll that never shows duplicate or skipped items

You are implementing infinite scroll for a paginated list. You use cursor-based pagination, not offset-based, and an IntersectionObserver to trigger the next fetch — and you explicitly guard against the duplicate-fetch and stale-request bugs that make naive infinite scroll implementations unreliable under real-world timing and real concurrent data changes.

LIST
An activity feed showing new posts from followed accounts, ordered newest first.

API PAGINATION SHAPE
GET /feed?cursor=<opaque_string>&limit=20 returns { items: [...], nextCursor: string | null }.

FETCH LIBRARY
TanStack Query v5, already used elsewhere in the app.

SCROLL RESTORATION REQUIREMENT
Yes — tapping a post to view its detail and pressing back must return to the exact same scroll position with the same items still loaded.

IMPLEMENTATION RULES
If the API supports cursor-based pagination — a token or an id marking where the next page should start — use it instead of an offset or page number, and explain why if the API only offers offset-based pagination: offset pagination is provably incorrect when items are inserted or removed between page fetches, because every subsequent page's starting position shifts by exactly the number of items that changed, producing either a duplicate item repeated across two pages or a skipped item that never appears at all, while a cursor tied to a specific item's identity is unaffected by insertions or deletions elsewhere in the list. Trigger the next page fetch using an IntersectionObserver watching a sentinel element near the end of the rendered list, not a scroll event listener — scroll events fire far more frequently than needed and require manual throttling to avoid janking the main thread, while IntersectionObserver is purpose-built for exactly this and fires only when the sentinel's visibility actually changes. Guard against firing a duplicate fetch for the same page: track whether a fetch for the next cursor is already in flight, in a ref or the fetch library's own status, and ignore any additional intersection trigger that fires while one is already pending — a fast scroll or a layout shift can trigger the observer's callback multiple times in quick succession before the first request even resolves. If the fetch library maintains its own cache and pagination state, such as TanStack Query's useInfiniteQuery, use its built-in mechanisms for tracking pages, next cursors, and in-flight status rather than duplicating that bookkeeping by hand alongside it. If scroll position must be restored — returning from a detail view back to the exact scroll position in the list — persist enough information to re-fetch or re-render every previously-loaded page up to that point, not just to set the numeric scrollTop value against a list that no longer has the same items loaded.

OUTPUT FORMAT
1. The pagination approach and fetch trigger, as real code.
2. The specific duplicate-fetch guard, shown explicitly, not left implicit in the fetch library's defaults.
3. Why cursor pagination was used, or an explicit note if the API only supports offset and what the accepted risk is as a result.
4. The scroll-restoration implementation, if required, or a note that it was not required and was left out.