fix(datatables): keep the current page across dataset refreshes - #13271

closes #13251

Changes:

Problem

Switching away from the Portainer tab and back sends any paginated table back to
page 1. It affects every list view — containers, stacks, images, volumes,
Kubernetes — not just one.

Cause

Datatable.tsx passes autoResetExpanded: false to useReactTable but leaves
autoResetPageIndex at its TanStack default of true. On every change of the
data array identity, getCoreRowModel's onChange calls
table._autoResetPageIndex(), which queues resetPageIndex() on a microtask.

React Query refetches on window focus, which produces a new array, so returning
to the tab resets the page. NestedDatatable.tsx has the same gap, and expanded
rows survive refetches (that is what autoResetExpanded: false is for), so
nested tables hit it too.

Fix

Set autoResetPageIndex: false in both components.

On its own that would strand the user: if the dataset shrinks — items removed, or
a search narrowing the results — the retained page index can point past the end
and the table renders empty with no obvious way back. So each component also
clamps pageIndex to the last available page when it falls out of range.

The clamp is skipped for server-side pagination, where the parent owns the page
state through the page / onPageChange props. That path already had
autoResetPageIndex effectively disabled via manualPagination: true, so its
behaviour is unchanged.

Note on #13221

#13221 addresses the same underlying defect for the containers view only, by
passing autoResetPageIndex: false through extendTableOptions in
ContainersDatatable.tsx. This change fixes it once in the shared components so
every table benefits, and adds the out-of-range clamp that the per-view fix does
not cover. Happy to rebase or close in favour of whichever the maintainers
prefer.

Tests

Added to Datatable.test.tsx and a new NestedDatatable.test.tsx:

• stays on the current page when the dataset is refetched
• falls back to the last available page when the dataset shrinks

Both were confirmed to fail before the change and pass after.

Verification

• pnpm test — 305 files, 2237 tests passing (baseline 2233, plus the 4 added)
• pnpm typecheck — 20 pre-existing errors, unchanged, none in the touched files
• pnpm exec eslint on the touched files — 0 errors, same 4 pre-existing warnings as on develop
• pnpm exec prettier --check — clean