Add a searchable select field type to the policy editor

What does this MR do and why?

The policy editor builds its forms from a catalog of field definitions. Its dropdown is a plain native select, which is fine for a handful of options and unusable for a long list. This adds a second dropdown type you can type into to filter the options. Nothing is user-visible yet — no policy form uses the new type until the follow-up work lands.

Details

• Adds a searchable_select field type wrapping GlCollapsibleListbox, registered in FIELD_TYPES and in the editor's field component map. The plain select type is unchanged and stays for short option lists.
• Filtering happens in the component: the listbox renders the search input and emits the term, but does not filter for you.
• Renders through the existing FieldWrapper, so it keeps the label, required marker and help icon, and points the listbox's accessible name at the label text rather than the whole label row.
• A value the catalog no longer offers shows as its raw id rather than as the placeholder, matching what the read-only policy summary does, so an author is not shown "Select..." over a value that is still set.
• The catalog guard spec that requires non-empty { id, label } options now covers this type too — without it a missing label throws on the first keystroke instead of degrading to a blank row.
• Frontend-only, under ee/app/assets/javascripts/policy_store/.

Why this is needed

The Setting Validation rule in the follow-up work picks from a curated list of project settings — long enough that scanning a native select is impractical. That rule lands in https://gitlab.com/gitlab-org/gitlab/-/work_items/630209, which is blocked on backend work, so this is the reusable half that can land now.

This MR was split out of a larger one. The other half — letting one field appear only when a sibling field has a particular value — is stacked on top of this branch in Add a searchable select field type to the polic... (!257013 - merged) (see References).

References

• Issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/630208
• Parent epic: https://gitlab.com/groups/gitlab-org/-/epics/23462
• Stacked on this MR: the sibling-aware fields half, branch 630208-sibling-aware-fields
• Follow-ups that add the first consumers: https://gitlab.com/gitlab-org/gitlab/-/work_items/630209 and https://gitlab.com/gitlab-org/gitlab/-/work_items/630210

Screenshots or screen recordings

Before	After
N/A — no catalog entry used the new field type

Recorded with a temporary scratch field added to catalog/rules.js to exercise the new type. The scratch entry is not part of this MR.

Where this gets used

The Setting picker on the Setting Validation rule in the design prototype (New policy → search the drawer for "settings" → Rules → Setting Validation) chooses from a curated list of project settings, so it needs to be filterable:

How to set up and validate locally

1. In ee/app/assets/javascripts/policy_store/catalog/rules.js, temporarily add a field with type: 'searchable_select' and an options array to a rule.
2. Open the group Policy Store, start a new policy, open the Rules tab, and pick that rule.
3. Confirm the listbox filters as you type and can be driven with arrow keys and Enter.
4. Select an option, then confirm the Clear control returns the field to its placeholder.
5. Revert the scratch edit to rules.js.
6. Run node_modules/.bin/jest ee/spec/frontend/policy_store --no-coverage.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.