Add the Policy Store Build step's building blocks

What does this MR do and why?

Adds the components the Build policy step composes, each with a focused spec — extracted ahead of the step itself so the step's MR reviews as wiring rather than five components at once:

Piece Job
serializer.js Form state ↔️ the shape the Policy Store API persists: rules as { type, value }, actions flat — matching what EE::Ci::ProcessBuildService reads back
catalog_group.vue One category of the drawer's catalog; owns the hover state for the info affordance
builder_section.vue One section of the policy being built: entries with joiner badges and expandable configuration, or an add button when empty. Selection and expansion state stay with the caller, so the step's "newly added entries auto-expand" behaviour remains possible
utils.js (groupCatalogItems) Pure function grouping a catalog for the drawer: search (via searchInItemsProperties), category order, label resolution, and a Custom fallback. A category the order does not know sorts last with its raw id as label rather than disappearing
BUILD_TAB_* Tab ids join editor/constants.js

Nothing mounts any of this yet — no behaviour change on master until the step lands.

Second of a three-MR chain extracted from !247891 (merged):

  1. !248392 (merged) — catalog categories (this MR's target; retarget to master when it merges)
  2. This MR — building blocks
  3. !247891 (merged) — the Build policy step itself (all UI, screenshots there)

References

Screenshots or screen recordings

No UI change. These components are unreachable until !247891 (merged) wires them into the wizard.

How to set up and validate locally

yarn jest ee/spec/frontend/policy_store/components/editor

35 tests across the four new suites.

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.

Merge request reports

Loading
Loading