Add work_item_type_names filter to Work Items REST API

What does this MR do and why?

Add a work_item_type_names array param to the Work Items REST API list endpoint so clients can filter by work item type NAME (including custom types), rather than only by integer type id.

Changes

• Finder (app/finders/issues/issue_types_filter.rb): Add by_work_item_type_names method wired into #filter. Resolves names case-insensitively via WorkItems::TypesFramework::Provider.new(parent) in a single pass. Unknown names yield an empty result set.
• Negation (app/finders/issues_finder.rb): Add by_negated_work_item_type_names alongside the existing by_negated_work_item_type_ids, resolving names the same way and feeding without_work_item_type_ids.
• REST exposure (lib/api/helpers/work_items/list_params.rb): Declare work_item_type_names (Array[String]) in both the top-level filter block and the not block. The param passes through WorkItemsFilterParams#transform unchanged (no renaming needed).
• EE finder specs (ee/spec/finders/issues_finder_spec.rb): Cover work_item_type_names and the negated variant using create(:work_item_custom_type, namespace: root_namespace); assert a custom-type name resolves and filters correctly.
• REST shared examples (spec/support/shared_examples/api/work_items_filter_shared_examples.rb): Add work_item_type_names contexts covering both case-insensitive matching and negation.

Database review

No migrations, no schema changes, no new columns or indexes.

This MR adds a work_item_type_names filter to the Work Items REST list finder.

Type names are resolved to work_item_type_id (in-memory, via WorkItems::TypesFramework::Provider#resolve_all no extra query), and the resolved ids reuse the existing Issue.with_work_item_type_ids / without_work_item_type_ids scopes.

The generated predicate is therefore identical to the already-merged work_item_type_ids filter (#605894); this change adds no new query shape.

Raw SQL

Positive filter — work_item_type_names[]=Task&work_item_type_names[]=Bug (names resolved to ids IN (5, 8); a single name collapses to = 5):

SELECT "issues".*
FROM "issues"
INNER JOIN "projects" ON "projects"."id" = "issues"."project_id"
LEFT JOIN project_features ON projects.id = project_features.project_id
WHERE (
    EXISTS (
      SELECT 1 FROM "project_authorizations"
      WHERE "project_authorizations"."user_id" = :user_id
        AND project_authorizations.project_id = projects.id
    )
    OR projects.visibility_level IN (0, 10, 20)
  )
  AND ("project_features"."issues_access_level" > 0 OR "project_features"."issues_access_level" IS NULL)
  AND "issues"."work_item_type_id" IN (5, 8)
ORDER BY "issues"."id" DESC
LIMIT 20;

Negated filter — not[work_item_type_names][]=Task (NOT IN / !=):

... AND "issues"."work_item_type_id" NOT IN (5)
ORDER BY "issues"."id" DESC
LIMIT 20;

Acceptance criteria

• GET /projects/:id/-/work_items?work_item_type_names[]=Bug returns only type "Bug" work items, including namespace-defined custom types.
• Case-insensitive: work_item_type_names[]=bug matches type "Bug".
• Multiple names OR together: work_item_type_names[]=Bug&work_item_type_names[]=Incident returns both.
• not[work_item_type_names][]=Bug excludes type "Bug".
• Unknown type name matches nothing (no error); all-unknown yields an empty result set.
• Works on both project and group list endpoints.

References

Closes #605891 (closed)

Screenshots or screen recordings

	Screenshot
No type filter
Filter by type name
Mutually exclusive with work_item_type_ids

N/A — REST API change only.

How to set up and validate locally

1. Start a local GitLab instance.
2. Create a project with work items of different types (e.g., Task, Issue).
3. Call the API:

   GET /api/v4/projects/:id/work_items?work_item_type_names[]=Task

4. Verify only Task work items are returned.
5. Test case-insensitivity: work_item_type_names[]=task should also return Tasks.
6. Test negation: not[work_item_type_names][]=Task should exclude Tasks.

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.