window.history.replaceState causes re-render in any component using useParams even if path parameters haven't changed.

### Link to the code that reproduces this issue https://github.com/Susannah-Parsons/ReRenderBug ### To Reproduce Install any dependencies `yarn install` Run in development mode `yarn dev` Open http://localhost:3000 with a browser equipped with React dev tools to see the homepage. Run the React dev tools profiler and record while you click the 'CHANGE HISTORY` button, then stop recording. The 'CHANGE HISTORY' button just runs the code ``` window.history.replaceState(null, "", `?test=test`); ``` ### Current vs. Expected behavior I would expect that, because the path params have not changed and nextjs documentation promises that window.history.replaceState() will not cause a rerender of the page, ClientComponent should not re-render. Instead of this, ClientComponent does re-render. This is a particular problem for anyone using a zustand store which persists state in the url search params using the window.history.replaceState() function, as any Component using useParams will re-render every time state is saved to the store. The bug appears to be tied to the use of the useParams hook. Any component using the hook will re-render on window.history.replaceState() even if the path parameters don't change. ### Provide environment information ```bash Operating System: Platform: linux Arch: x64 Version: #1 SMP Thu Jan 11 04:09:03 UTC 2024 Binaries: Node: 20.11.0 npm: 10.2.4 Yarn: 1.22.19 pnpm: 8.15.6 Relevant Packages: next: 14.1.4 eslint-config-next: N/A react: 18.2.0 react-dom: 18.2.0 typescript: 5.3.3 Next.js Config: output: N/A ``` ### Which area(s) are affected? (Select all that apply) App Router, Routing (next/router, next/navigation, next/link) ### Which stage(s) are affected? (Select all that apply) next dev (local), next build (local), next start (local), Vercel (Deployed), Other (Deployed) ### Additional context I was unable to test against the latest canary, as my app crashes on start with the latest canary. It is still an issue on 14.2.0-c…