fix(edit-content): fix pagination in relationship field not changing displayed items

[oidacra]

Summary

• Fix relationship field pagination that showed the same items on every page because p-table bound the full data array with [paginator]="false", ignoring [first] and [rows]
• Add a paginatedData computed signal that slices data by offset/rowsPerPage, fix row reorder to translate paginated indices, and reset pagination on item deletion when current page becomes invalid

Closes #35106

Changes

File	Change
core-web/.../store/relationship-field.store.ts	Add paginatedData computed signal; update deleteItem to reset pagination when current page exceeds total
core-web/.../dot-relationship-field.component.html	Bind [value] to store.paginatedData() instead of store.data(); fix isEmpty check to use full data
core-web/.../dot-relationship-field.component.ts	Fix onRowReorder to translate slice-local indices to global positions using pagination offset
core-web/.../store/relationship-field.store.spec.ts	Add tests for paginatedData (first page, second page, empty, reactive) and deleteItem pagination reset

Acceptance Criteria

• The p-table's [value] binding receives only the items for the current page, not the entire data array
• Clicking "next page" advances to the next page and displays only that page's items
• Clicking "previous page" navigates back and displays only the previous page's items
• Each page displays at most rowsPerPage items (currently 6). Last page may display fewer
• Previous button disabled on page 1, next button disabled on last page (no regression)
• When items are deleted such that current page exceeds total pages, pagination resets to last valid page
• Drag-and-drop row reorder works correctly with paginated data (indices translated by offset)
• When ≤6 items, no pagination controls appear (no regression)
• Original bug STR no longer reproduces
• Store has unit tests for the paginatedData computed signal

Test Plan

• Open Edit Content for a content type with a relationship field
• Add more than 6 related items — pagination should appear showing "1 of 2"
• Click next page — different items should be displayed
• Click previous page — original items should be displayed
• On page 2, delete all items — should automatically go back to page 1
• Drag-and-drop reorder items on page 1 — order should persist correctly
• With ≤6 items, no pagination controls should appear
• Run yarn nx test edit-content --testPathPattern=relationship-field.store.spec — all tests pass

Visual Changes

Screenshots/GIFs needed: This PR includes frontend changes. Please attach visual evidence before marking as ready for review.

• Before screenshot
• After screenshot
• GIF of interaction (if behavioral change)

This PR fixes: #35106

[claude]

Claude finished @oidacra's task in 1m 31s —— View job

---

PR Review

• Read changed files
• Analyze for bugs, edge cases, design issues
• Post review

---

Issues Found

1. onRowReorder resets pagination to page 1 after every drag — medium bug

onRowReorder calls store.setData(reorderedData), and setData unconditionally resets pagination to { offset: 0, currentPage: 1 }:

// relationship-field.store.ts:113-118
setData(data: DotCMSContentlet[]) {
    patchState(store, {
        data: [...data],
        pagination: { ...store.pagination(), offset: 0, currentPage: 1 }
    });
}

A user on page 2 who drags a row will be silently transported back to page 1. The setData reset is intentional when replacing the whole set (e.g., after the selection dialog), but onRowReorder is a reorder-in-place — it should preserve the current page. Fix: extract a reorderData store method (or patchState directly) that does not touch pagination, or restore pagination after calling setData. Fix this →

2. nextPage() / previousPage() have no bounds-checking in the store

Both methods blindly increment/decrement without checking against totalPages or 0:

// relationship-field.store.ts:196-216
nextPage: () => {
    patchState(store, {
        pagination: {
            ...store.pagination(),
            offset: store.pagination().offset + store.pagination().rowsPerPage,
            currentPage: store.pagination().currentPage + 1
        }
    });
},

If the pagination component has a render bug or a test drives the store directly, the offset can exceed the data array length or go negative. The paginatedData slice would silently return [] with a positive invalid offset, which would show an empty page with no UI indication. Not a current bug, but fragile. Guard would be trivial: if (store.pagination().currentPage < store.totalPages()).

3. Dead bindings on <p-table>

[first]="pagination.offset" and [rows]="pagination.rowsPerPage" (template lines 17–18) are now inert because [paginator]="false" tells PrimeNG to ignore them. They were meaningful under the old design; now they're misleading. Should be removed to avoid confusing future readers.

4. Missing test coverage for the onRowReorder offset translation on page 2+

The store's paginatedData is well-tested. The onRowReorder logic that translates paginated indices to global ones is not: there's no unit test that navigates to page 2 and asserts that a reorder on that page updates the correct global indices. The E2E reorder test only uses 3 items (no pagination). This leaves the translation (offset + dragIndex) untested by anything that would catch a regression.

---

The core pagination fix is correct and the split between paginatedData (store) and the template binding is clean. Issues 1 and 4 are the meaningful ones — the reorder page-reset is a real UX regression that users will notice.