Feature summary (what you would like to be able to do and where):
5,000 results on the 'get edits' check results is often too many for a browser tab to load without lagging out from my experience. As CUs have no way to currently set a limit until the check has been run, when running a check on a large range the page is likely to lag a fair amount. The CU could choose a number that is best suited to their workflow, whether that be maximum results or better loading times

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Would allow CUs to specify a per-user limit through the preferences to help address the lag that check on the 'get edits' results often have.

Benefits (why should this be implemented?):
Since paging has been implemented for all but the Get IPs results (see T315612) there is no longer a need to have maximum possible results on a check as the check can be split up into multiple parts. The default per-user limit would remain at 5,000 as that is outside the scope of this task, but this would allow CUs to choose the proportion of number of results to loading time.