Do not log a search count request that timed out

What does this MR do and why?

The search page sidebar requests a result count for each inactive scope tab from /search/count, and facets from /search/aggregations. When the search query times out, SearchController#render_timeout answers HTTP 408 with an empty body. It also calls log_exception, which reports the timeout to error tracking. The main page shows "Your search has timed out". A timeout is an expected state, not a defect.

The frontend store actions fetchSidebarCount and fetchAllAggregation still called logError on every 408. That wrote one console error per inactive tab and added nothing: logError only writes to the browser console, and the server had already reported the event. The sidebar already shows a dash when a count is missing, so no user-visible behavior changes.

The fix skips the client-side log for a 408 from these two endpoints:

• app/assets/javascripts/lib/utils/http_status.js
  • adds HTTP_STATUS_REQUEST_TIMEOUT (408)
• app/assets/javascripts/search/store/actions.js
  • adds a small isSearchTimeout helper
  • fetchSidebarCount and fetchAllAggregation skip logError when the status is 408
  • fetchAllAggregation still commits RECEIVE_AGGREGATIONS_ERROR on 408
  • other errors (network failure, HTTP 500) are still logged
• spec/frontend/search/store/actions_spec.js
  • adds a 408 row per action; both assert zero logError calls, the aggregations row also asserts the error mutation

Only SearchController#render_timeout answers 408 on these endpoints. A code comment states this.

How it was found: the console-error baseline check in feature specs (MR !255207 (closed), part of work item 628901) fails an example when the browser console shows an unexpected error. The failing examples are the "when search times out" examples in user_searches_for_issues_spec.rb, user_searches_for_merge_requests_spec.rb, and the shared example search_timeouts_shared_examples.rb, which nine spec files include. Those specs stub SearchService#search_results to raise ActiveRecord::QueryCanceled on purpose. allow_next_instance_of without a count stubs every SearchService instance, and each count request builds its own, so every tab count also returned 408. The timeout in tests is intentional. The noise is not a test environment problem.

Alternative ruled out: allow-list the console message in those spec files. That would hide the message in tests only and leave real users with one console error per tab on every real timeout.

Screenshots or screen recordings

Not applicable. Only console output changes.

How to set up and validate locally

1. Run yarn jest spec/frontend/search/store/actions_spec.js.
2. In GDK, open /search?search=test&scope=issues with the browser console open.
3. Use the browser network tools to make /search/count respond 408.
4. Reload. Confirm the sidebar tabs show a dash and the console shows no [gitlab] Error: Request failed with status code 408.
5. Make a count request respond 500 and confirm that error is still logged.

MR acceptance checklist

This MR has been evaluated against the acceptance checklist.

References

• Part of section D of #628901
• Console baseline check that revealed the noise: !255207 (closed)
• Pipeline jobs showing the failing timeout examples: https://gitlab.com/gitlab-org/gitlab/-/jobs/16462296252 and https://gitlab.com/gitlab-org/gitlab/-/jobs/16462296256