Fix push list resetting to latest 10 pushes on query param changes

[camd]

Problem

Users paging back through pushes ("get next N") or toggling filters would sporadically have the jobs view clear and re-render — sometimes resetting to the latest 10 pushes — losing their place while searching for a push. There was no clear STR; it "seemed related to adding or removing query string parameters."

Root cause

The app had URL writers that React Router never saw:

• replaceLocation() / setUrlParam() (ui/helpers/location.js) wrote the URL with a raw window.history.pushState (despite the name), with no popstate dispatch.
• PushList.fetchNextPushes did the same when rewriting revision=X → tochange=X (and dropping startdate) for "get next N".

React Router's location.search (and PushList's prevRouterSearch) went stale. The next popstate-dispatching action — clicking a job, clicking empty push-list space (clear-selection handler), toggling a filter, or the back button — woke the router, and PushList.handleUrlChanges compared the stale search against the new one, misreading the long-gone revision/startdate params as a range change. That triggered updateRange() → clearPushes() + fetchPushes(): the whole push list wiped and refetched, falling back to DEFAULT_PUSH_COUNT = 10 when the URL had no fromchange. The outcome depended on how raw writes interleaved with router-visible navigations, which is why no reliable STR existed.

Deterministic STR (reproducible on production): open /jobs?repo=autoland&revision=<sha>, click "get next 10", then click any empty space in the push list → entire page clears and refetches.

Fix

Single-writer principle — every URL mutation is now visible to React Router:

• replaceLocation() delegates to replaceUrlSearch(): true replaceState semantics (it previously pushed, bloating history on every fromchange rewrite and param normalization) plus a popstate dispatch so the router stays in sync.
• fetchNextPushes uses updateUrlSearch() and preemptively updates prevRouterSearch so the intentional revision → tochange rewrite is not treated as a range change.

Side benefit: browser Back after "get next" now lands on a consistent single-revision state, since the address bar and router agree at every step.

Tests

• New tests/ui/job-view/PushListUrlDrift_test.jsx reproduces both the router/URL drift and the spurious clear-and-refetch. It deliberately uses BrowserRouter — MemoryRouter cannot observe raw history writes, which is why existing tests never caught this. Both tests fail on master and pass with this fix.
• pushes_test.jsx updated to assert replaceState instead of the old raw pushState implementation detail; PushList_test.jsx now stubs replaceState alongside pushState to keep the jsdom URL isolated between tests.
• Full frontend suite green: 92 suites / 1036 tests.
• Hand-verified in the browser: bug reproduces on production, does not reproduce with this branch.