Paginate Data Management backup inventory and job history #1096

Summary

Add server-side pagination to the Admin Data Management backup inventory and job history so administrators can navigate complete histories without fixed 25/100-row truncation or loading every record into the browser.

User Value

Backup and migration histories grow continuously. Administrators need predictable navigation, filtering, and counts across the full history, especially when diagnosing long-running, failed, skipped, canceled, or overlapping operations.

Proposed Behavior

• Replace fixed-limit list contracts with stable continuation-token pagination for /api/admin/data-management/jobs and /api/admin/data-management/backups.
• Use deterministic ordering with a tie-breaker, opaque server-validated continuation state, bounded page sizes, and explicit has_more/next-token response fields.
• Add server-side filters appropriate to each list: operation, backup type, status, scheduled/manual, and a bounded date range where supported.
• Keep backup summary counts and latest-full/latest-partial information independent of the current page; do not derive global totals from one page of records.
• Add compact accessible pagination controls to both tables, preserving filter state across next/previous navigation and refresh.
• Prevent stale/out-of-order browser responses from replacing a newer page or filter result.
• Reset pagination deliberately when filters change and preserve the current page during live job-detail refresh where possible.
• Keep responses sanitized and never embed raw settings, destination details, credentials, SAS URLs, or unbounded item logs.

Acceptance Criteria

• Job history and backup inventory can navigate beyond the current 25- and 100-record limits without missing or duplicating rows in an unchanged dataset.
• APIs accept bounded page size and opaque continuation input and return deterministic page metadata.
• Backup type/status and job operation/status filters execute server-side and pagination state resets correctly when filters change.
• Global backup summary counts and latest backup references remain correct regardless of page size or active filter.
• Admin UI provides accessible previous/next controls, page status, loading/empty/error states, and responsive table behavior.
• Refresh and overlapping requests cannot render stale results over the latest selected page/filter.
• Invalid or expired continuation input fails safely without leaking query internals.
• Functional route tests and authenticated browser tests cover multi-page navigation, filters, ordering ties, empty/final pages, invalid tokens, and sanitization.

Notes

• Current job history requests limit=25; backup inventory requests limit=100, and both backend helpers slice materialized query results.
• The existing Cosmos editor continuation-token implementation is a nearby pattern, but list tokens must also bind to normalized filters and sort contract.
• Related to Make Data Management backup jobs durable, cancellable, and overlap-safe #1092 and Make Data Management migrations resilient for large blob transfers with cancel, resume, and incremental sync #1043, but independently implementable.