Add distinct alert for bulk edit GraphQL timeouts

What does this MR do and why?

Frontend-only change to bulk editing in the group and project work item lists. Every failure previously showed the same generic alert, "Something went wrong while bulk editing.", even though a GraphQL timeout (graphql_timeout defaults to 30 seconds) arrives as a Timeout on WorkItemBulkUpdate.updatedWorkItemCount entry in the response errors array, not a failed request, so it looked like any other failure.

A helper now detects that timeout among the per-chunk failures and shows a distinct alert: "Bulk edit took too long, try selecting fewer work items." Other failures keep the generic message; both report to Sentry.

The timeout path also emits the component's existing success event, so list_view.vue closes the sidebar and evicts the cached list so it refetches, as after a normal bulk edit, with refetchCounts unchanged. That is safe because Promise.allSettled holds the alert until every chunk has returned, and a timed-out chunk cannot error before its save finishes.

It is scoped to the timeout path because other failures (a client abort, or rack-timeout at 60 seconds) surface as a network error and can leave a partial update, since each item is saved separately, so they keep the generic alert without a refresh.

Requested in review on the linked work item, which this MR relates to but does not close.

Files changed: app/assets/javascripts/work_items/list/components/work_item_bulk_edit_sidebar.vue, its Jest spec, and locale/gitlab.pot for one new string.

References

• Work item this relates to: #606918 (closed)
• Review comment requesting this change: #606918 (comment 3816582535)
• Related backend performance MR already in review: !254662 (merged)
• Longer-term fix, moving bulk updates to a background job: #572140

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. In config/gitlab.yml, set graphql_timeout: 2 under gitlab: (default 30), and add sleep 5 as the first line of resolve in app/graphql/mutations/work_items/bulk_update.rb, so only the mutation passes the limit and page queries still work.
2. Restart Rails, open a work item list, select work items, open the bulk edit sidebar, change the state, and submit.
3. Expected result: the alert reads "Bulk edit took longer than expected. The list has been updated." and appears as a blue info alert rather than a red danger one.
4. Check that the sidebar closes and the list refreshes, with edited values and tab counts updating without a manual reload.
5. Revert both local edits afterwards.

To run the Jest spec: yarn jest spec/frontend/work_items/list/components/work_item_bulk_edit_sidebar_spec.js

Worth noting: the spec resolves the Apollo handler with { data, errors }, since rejecting it produces a networkError instead.

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.