Issues list pagination returns inconsistent total counts and fewer than requested items per page

### Environment SaaS (https://sentry.io/) ### Steps to Reproduce 1. Navigate to the Issues page for a project with ~100 issues 2. Set the time period to 90 days with an empty query (query=) 3. Page through all results using the pagination arrows 4. Observe the "X–Y of Z" pagination caption and the actual number of items on each page ### Expected Result - The total count ("of Z") should remain consistent across all pages - Each page (except the last) should return exactly 25 items - Page ranges should be contiguous with no gaps or overlaps (e.g., 1–25, 26–50, 51–75, etc.) ### Actual Result The X-Hits response header changes between pages, and some pages return fewer than 25 items from the API even though more results exist on subsequent pages. Verified via HAR capture across all 5 pages: Page 1 (no cursor): X-Hits: 97, items returned: 25 Page 2 (cursor=1769385638000:0:0): X-Hits: 96, items returned: 25 Page 3 (cursor=1767387672000:0:0): X-Hits: 96, items returned: 19 Page 4 (cursor=1766086092000:0:0): X-Hits: 96, items returned: 25 Page 5 (cursor=1763066071000:0:0): X-Hits: 96, items returned: 3 All 97 group IDs are unique across pages (no duplicates, no missing groups), just unevenly distributed. The frontend assumes 25 items per page when calculating the "X–Y of Z" display (page * MAX_ITEMS), so the short pages cause gaps and overlaps in the displayed ranges. This was tested with an empty query (no is:unresolved or other filters), so the auto-resolve post-filter at organization_group_index.py:380 should not be a factor. A separate but related issue was previously observed by the reporting customer when using the is:unresolved filter, where the UI showed "1–0 of 37" (zero results with a non-zero total). This may still be relevant for filtered queries. See Linear ticket for the internal ZD case for more information. ### Product Area Issues ### Link _No response_ ### DSN _No response_ ### Version _No response_