base-data-service: fetchInfiniteQuery duplicates a page when a stale cached page is requested again

`BaseDataService.fetchInfiniteQuery` (query-core v5) appends a later page straight into the infinite cache without checking whether it is already there. Re-requesting a page that is already cached fetches it again and merges it, so the service's cache ends up with duplicated and out of order pages.

The realistic trigger is a refetch. When a UI's stale infinite query rebuilds, query-core re-requests each page through the service, so page 2 is requested again. Verified with `createUIQueryClient` and an `InfiniteQueryObserver` against the live behavior: after scrolling to page 2 (service cache params `[1, 2]`), a refetch leaves the service cache at `[2, 1, 2]`, and each further refetch grows it (`[2, 1, 2, 3]`, and so on).

The UI observers are not directly affected: query-core rebuilds each observer's own result cleanly, so users do not see duplicate items. The impact is on the service's shared cache, which accumulates duplicate and misordered pages over time (unbounded growth across refetches), and a newly hydrating observer can briefly receive the corrupted pages before its own fetch rebuilds them.

This is existing behavior, not a v5 regression. Verified against `@tanstack/query-core` 4.43.0: v4 also duplicated on every repeat request.

Suggested fix: before merging, if the requested page param is already present, replace that page in place instead of appending or prepending.

Scoped out of the query-core v5 bump (#9712), where Bugbot originally flagged it.

Start by locating BaseDataService.fetchInfiniteQuery and reproduce the behavior with createUIQueryClient and an InfiniteQueryObserver. Check the service cache params after scrolling and refetching; done means an already cached page is replaced in place without duplicate or reordered pages, including across repeated refetches.

Written by the indexing model from the issue text.