Fix pagination footer ignoring the active list filter

[ianmuchyri]

Problem

On every CRUD list page, typing into the filter box narrowed the displayed rows but left the pagination footer showing the unfiltered count.

Searching /entities for a term matching one entity showed a single row above a footer reading 350 rows … Page 1 of 18. /groups behaved identically (94 rows … Page 1 of 5).

Root cause

The search box was never wired to the backend. It writes <resource>.q into the URL, but CrudWorkspace only forwarded resource.filters entries and status to GraphQL — never q. So the list query always fetched an unfiltered page, and DataTable narrowed those rows in the browser:

// Client-side filter of the current page — useful when backend has no text search.
const filteredData = data.filter((row) => { … });

The footer then printed the server's total, which still counted the whole unfiltered set. Rows and count came from two different notions of "the result set".

This also meant search only ever matched rows that were already on the visible page — searching for something on page 5 while viewing page 1 found nothing.

Fix

• Forward the search term as q on the list queries whose resolver accepts it — tenants, entities, groups, resources, roles — so the backend narrows rows and total together and the filtered set pages correctly.
• Pass serverFilters down to DataTable so it knows which filters were already resolved server-side. It skips re-filtering those (re-applying the browser's broader JSON.stringify match would drop valid backend matches).
• For resources with no backend text search (profiles, permissionBlocks, actions, actionApplicability, actionAssignmentRules, directPolicies) the client-side fallback stays, but the footer now counts the rows it actually filtered instead of reporting a total that no longer describes them.
• Clamp the displayed page to the available range so a collapsed result set cannot render Page 7 of 1.

Fixed in the one shared component, so it applies to every list page.

Scope note

This bug predates #69 and #82 — neither caused it. It was found while QA-testing their UI, not introduced by them. #69 is Rust/GraphQL backend only, and #82 touched only the inspect sheets, object-group-*, object-access-panel.tsx, lib/access/ and lib/object-groups/ — none of the shared list/table/pagination plumbing. The client-side filter block responsible dates back to 40e1512 "Add initial admin UI (#1)".

Test plan

Manual (browser, dev UI on :3012 against the running backend on :8080, ~350 entities / 94 groups)

Before the fix:

Page	Filter	Rows shown	Footer
/entities	qa-test-entity-3	1	❌ 350 rows, Page 1 of 18
/groups	qa-test-group-2	1	❌ 94 rows, Page 1 of 5

After the fix:

Page	Filter	Rows shown	Footer
/entities	qa-test-entity-3	1	✅ 1 row, Page 1 of 1
/groups	qa-test-group-2	1	✅ 1 row, Page 1 of 1

Regression checks, all after the fix:

• Unfiltered still correct — /entities 350 rows / Page 1 of 18, /groups 94 rows / Page 1 of 5, matching the pre-fix unfiltered baseline.
• Unfiltered paging — /entities?entities.page=2 → Page 2 of 18, 20 different rows, all four page links enabled.
• Filtered paging across pages — /entities?entities.q=tenant&entities.limit=10 → 12 rows / Page 1 of 2, 10 rows, Next preserves q; page 2 → Page 2 of 2, remaining 2 rows, search box still shows tenant, Next/Last correctly disabled.
• Clearing the filter — typed then cleared in the box on /groups; returned to 94 rows / Page 1 of 5 with paging re-enabled.
• Other newly-$q resources — /tenants?q=demo 2 rows, /roles?q=admin 57 → 6 rows, /resources?q=telemetry 1 row. No Backend unavailable alerts.
• Client-side fallback intact — /profiles?profiles.q=Gateway (no backend q) still filters to 1 row and the footer reports 1 row.
• Console — no new errors or warnings.

Automated

• pnpm lint — clean (178 files).
• pnpm test — 25 files, 103 tests passing.
• pnpm build — compiles successfully.

Added 5 tests to components/ui/data-table.test.tsx. Verified they are real regression tests: reverting data-table.tsx to its pre-fix state fails 4 of them with exactly the reported symptom (expected 'ViewNameneedle350 rows…' to contain '1 row'), and they pass with the fix.