Experiments Portlet — swap the List to the server-side contract

Description

#36989 ships the list against GET /api/v1/experiments as it exists today, computing paging, sorting, filtering, status counts and site scoping client-side — an explicit, documented interim. This issue replaces that interim with the server-side contract from #36823, and is filed together with #36989 on purpose so the interim cannot quietly become permanent. It lands whenever #36823 does; nothing else waits on it.

The URL param contract was designed to be final from day one, so this swap changes where the params are applied, not what they are called.

Scope

• Replace client-side paging / sorting / text filtering / status filtering / site filtering / status counts with the server-side parameters from #36823 (page, per_page, orderby, direction, filter, status, goal, siteId).
• Add two new toolbar filter controls — filter by creator and filter by running date range — consuming #36823's created_by and running_from/running_to parameters.
• Consume the enriched rows: real pageTitle / pageUrl / site in the Page column, deleting #36989's interim client-side page lookup.
• Consume the per-status counts from the API instead of counting the loaded array.
• totalRecords from the response body (pagination.totalEntries), not the X-Pagination-* headers.
• Enable server-side filtering only against a build where #36823's two SQL fixes are merged (name+status malformed SQL; pageId+multi-status precedence).

Boundary check

Only two places should change in existing code: the data-access service and the store's load event handler. No existing component should need touching — the one enumerated exception is the two new toolbar filter controls (creator, running date range), which are new components this issue adds. If any other component needs a change, #36989's service boundary was drawn wrong — flag it in review instead of patching around it.

Acceptance Criteria

• The list issues one request per view change carrying the server-side params; no client-side slicing/sorting/filtering remains (interim utilities deleted).
• URL behavior is byte-identical for all pre-existing params: same names, same defaults-omitted rule, same deep-link restoration (the E2E deep-link spec from #37006 passes unchanged). The three new params (created_by, running_from, running_to) are additive and follow the same defaults-omitted rule.
• Page column shows the enriched title/path; the interim lookup is deleted.
• Status counts come from the API and reflect the whole filtered set.
• Site scoping uses the siteId param; switching site refetches.
• Diff touches only the data-access service, the store load handler, the two new toolbar filter controls, and deleted interim code.
• Filter by creator works server-side via created_by; filter by running date range works server-side via running_from/running_to with inclusive overlap semantics; both compose with every other filter and are reflected in counts and totals.
• Jest specs updated: load handler asserts outgoing params per state.

Priority

Medium — unblocks scale, not features.

Additional Context

• Depends on: #36823 (merged, including permission filtering) + #36989.
• Out of scope: any visual or interaction change to the list; any endpoint change (pure consumer swap).

Start with the data-access service and the store's load event handler changed by #36989, then review the two new toolbar filter controls and their Jest specs. Use #36823 for the server-side parameter contract and #37006 for the unchanged deep-link behavior. Done means requests carry the view state, enriched rows and API counts are consumed, interim client-side logic is removed, and the listed specs pass.