[web] Changing of filters and the reset of the page in the Reports table does not adjust the page= GET parameter, which can lead to out of bounds visualisation when used as a permalink or through the "Back to Reports" button

[whisperity]

Describe the bug
The user's choice on which page they are during the pagination of the reports is kept even when the filters change and the selected page is now out of bounds.

CodeChecker version
6.23 release

To Reproduce
Steps to reproduce the behaviour:

1. Store many reports in a way that you can filter for a "large" and a "small" set.
   • Preferably, the "large" set should be larger than the page size and the small set should be smaller than the page size. In this concrete example, I'm using 50 as the page size, the large set is 917 elements, and the small set is 28. (So a 25 page size would not suffice!)
2. Filter for the "large" set and go some pages forward in the report list,
   • https://codechecker-demo.eastus.cloudapp.azure.com/Default/reports?is-unique=off&run=%2allvm-master-version&diff-type=New&checker-name=bugprone-chained-comparison&analyzer-name=clang-tidy&sort-by=bugPathLength&sort-desc=true&items-per-page=50&page=4
3. Now change the filters such that the "small" set is filtered.
4. Observe that the filter now shows the small set properly (e.g., in my example, 50 rows per page, showing the "1-28 of 28" results), but the URL still says &page=4.
   • (I can't directly link this step, because that way, the observation would differ!)
5. The report page works and shows the newly filtered data, open a report at random.
   • For example, https://codechecker-demo.eastus.cloudapp.azure.com/Default/report-detail?is-unique=off&run=%2allvm-master-version&diff-type=New&checker-name=bugprone-crtp-constructor-accessibility&analyzer-name=clang-tidy&sort-by=bugPathLength&sort-desc=true&items-per-page=50&page=4&report-hash=f603e90d0a84cef40e9148803b226621&report-id=4117879&report-filepath=%2Flocal%2Fpersistent_docker%2FCSA-measurements-driver-3023%2Fmeasurements_workspace%2Fcontour%2Fbuild%2F_deps%2Frange_v3-src%2Finclude%2Frange%2Fv3%2Fview%2Fadaptor.hpp
6. Use the "Back to Reports" button such that you return to the report list.
7. Now the report list says No data available, Rows per page: 50, 1-0 of 28 (this is strange!), because we are still on &page=4, as seen in the URL.
   • We are led to https://codechecker-demo.eastus.cloudapp.azure.com/Default/reports?is-unique=off&run=%2allvm-master-version&diff-type=New&checker-name=bugprone-crtp-constructor-accessibility&analyzer-name=clang-tidy&sort-by=bugPathLength&sort-desc=true&items-per-page=50&page=4 in this example.
8. The user has to click the < button 3 times (because we are on page 4, but there is no indication of this fact anywhere except if mined from the URL!) to get back to the "normal" result page.

Expected behaviour
The filter reapplies after detecting that it's on the wrong page OR when fixing the filtered list in step 3, the &page= in the GET params is set to 1 or something.

Desktop (please complete the following information)

• OS: Windows 10 22H2
• Browser: Firefox
• Version: 118.0.1