Motir

Estimate: 20m · Depends on: 2.5.4, 2.5.8, 2.5.10

Make the flat List server-paged per the 2.5.10 design (finding #57). Through the 4-layer path: findProjectIssuesFlat gains limit/offset + a sibling COUNT query over the same filter (the count is of the FILTERED set); getProjectIssuesList returns { items, total, page, pageSize }; the /issues route reads ?page= (parsed/clamped in issueListView beside parseSort) and passes it down; the List table renders the pagination bar (range + prev/next + page jumps) per the design. ?page composes with ?view/?sort/filter and is part of the Suspense key so a page change re-streams the skeleton. Page size is the design's constant.

Acceptance criteria

• The List fetches + renders one page (default 50) with a "1–50 of N" bar; prev/next/page-jump update ?page and re-stream; the count reflects the active filter.
• Paging is server-side (LIMIT/OFFSET + count) through Route → Service → Repository — no raw Prisma in the route, no client-side slicing of a full fetch.
• Out-of-range page clamps to the last page; empty/filtered-empty states intact; sort + filter still work under paging.
• Integration test (real PG): page boundaries + filtered count; component test: the bar drives ?page. tsc/eslint/prettier clean; next build compiles.

Context refs

• lib/repositories/workItemRepository.ts findProjectIssuesFlat + lib/services/workItemsService.ts getProjectIssuesList + lib/issues/issueListView.ts (parseSort/serializeSort → add parsePage)
• app/(authed)/issues/page.tsx + IssueListTable / IssueListToolbar
• The 2.5.10 design asset (List pagination) — the layout authority