Guard in-flight sync polls against page, sort, and coverage changes

`pollSync` captures the coverage and cursor before its request, but after the `await` it checks only `isMountedRef` before writing `cursorRef.current = delta.cursor` and merging rows (`src/admin/utils/entries-api.ts`). The page-fetch effect has its own `cancelled` flag, and since the #23 fix round the cursor is reset on coverage change — but nothing invalidates a poll that is already in flight.

Effects:

- A poll started before a page or sort change lands afterwards and overwrites the fresh page cursor with one derived from the previous cursor. The next poll re-requests rows already on the page and re-classifies them, firing spurious "Updated" snackbars. A tab regaining focus fires an immediate poll, which makes the window easy to hit.
- Narrower variant: an in-flight poll from a previous coverage can land after the reset and restore the old coverage's cursor. In-app navigation unmounts the view, so this needs a fragment-only URL change between coverages.

Direction: a generation counter shared by the page fetch and the poll — bumped on every page fetch and coverage change, compared after the `await` — or an `AbortController` cancelling in-flight polls on those transitions. Either closes both cases.

Raised in the #23 review; split out as a follow-up by decision there.

Start in src/admin/utils/entries-api.ts and trace pollSync alongside the page-fetch effect, including their coverage, cursor, page, and sort transitions. Verify how an awaited poll response is accepted after each transition, then confirm that stale responses no longer change the cursor, rows, or update notifications; the existing #23 review provides context for the regression.

Written by the indexing model from the issue text.