Cap max_file_match_results in standard search to reduce response size

What does this MR do and why?

For standard (non-multi-match) search when offset pagination is not active, max_file_match_results returns UNLIMITED (0). This causes the coordinating node to return all matching files (up to ~5,000) in the JSON response, even though Rails only consumes at most max(Cache::MAX_PAGES, current_page) * per_page results.

This MR caps max_file_match_results behind the zoekt_cap_file_match_results feature flag to request only as many files as Rails will actually consume:

• Page 1: max(10, 1) * 20 = 200 files
• Page 5: max(10, 5) * 20 = 200 files (cache covers pages 1-10)
• Page 15: max(10, 15) * 20 = 300 files
• Page 50: max(10, 50) * 20 = 1,000 files

The coordinating node still collects and ranks across the full 5,000 line match window (max_line_match_window). The cap only affects the post-sort trim of the returned JSON.

Priority of max_file_match_results logic

1. Multi-match: returns search_limit (unchanged)
2. zoekt_cap_file_match_results enabled: returns max(current_page, MAX_PAGES) * per_page (new)
3. Offset pagination active: returns existing offset pagination logic (unchanged)
4. Default: returns UNLIMITED (unchanged)

Feature flag

zoekt_cap_file_match_results - gitlab_com_derisk type, disabled by default.

References

Relates to #591910

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.