[TASK] Content Drive: Add Workflow filter (Scheme → Step) to the toolbar

[zJaaal]

Description

Add a Workflow filter to the Content Drive toolbar, allowing users to narrow the content listing by workflow scheme and workflow step.

This filter should mirror the existing content-type filter (dot-content-drive-content-type-filter), which uses a two-column popover: the left column lists the parent dimension and the right column lists the children narrowed by the focused parent. For this filter:

• Left column → Workflow Schemes
• Right column → Steps belonging to the focused scheme

Selecting a scheme with no step narrowing filters by "all steps of that scheme"; selecting specific steps narrows further (same cascade-up / cascade-down behavior the content-type filter uses between base types and content types).

Reference / pattern to follow

Piece	Reference file
Filter component	libs/portlets/dot-content-drive/portlet/src/lib/components/dot-content-drive-toolbar/components/dot-content-drive-content-type-filter/
Toolbar wiring	dot-content-drive-toolbar/dot-content-drive-toolbar.component.html
Store filters API	store/dot-content-drive.store.ts (patchFilters, removeFilter, getFilterValue)
Query builder	utils/functions.ts → buildContentDriveQuery
Filter types	shared/models.ts → DotKnownContentDriveFilters
Shared UI	DotChipFilterComponent, DotFilterListItemComponent (@dotcms/portlets/content-drive/ui)

Technical notes

• Add the new filter key(s) to DotKnownContentDriveFilters (e.g. workflowScheme, workflowStep / wfStep). The query builder already handles string[] filter values generically (+key:(a OR b)), so wiring a new multi-select key requires no changes to buildContentDriveQuery beyond confirming the correct Lucene field names for the index (e.g. wfScheme, wfStep).
• Persist selection through the store's patchFilters / removeFilter like the content-type filter does, so URL encode/decode round-trips for free via encodeFilters / decodeFilters.
• Source data: workflow schemes and their steps come from the workflow service/API — confirm the available endpoint(s) for schemes → steps before building.
• Register the component in the toolbar's filter row alongside dot-content-drive-content-type-filter and dot-content-drive-language-field, and ensure it participates in the existing Clear all filters action.
• Follow project conventions: dot- prefix, standalone, @if/@for, input()/output(), i18n keys via DotMessagePipe, data-testid on interactive elements, Jest + Spectator tests.

⚠ Open question — multi-select vs single-select

It is not yet decided whether scheme/step selection should be multi-select (matching the content-type filter, which allows multiple base types and content types) or single-select. This needs to be resolved before/while implementing:

• Multi-select → reuse the content-type filter's chip + cascade behavior verbatim.
• Single-select → simpler popover, single chip, no cascade.

The acceptance criteria below assume the multi-select pattern for parity with the existing filter; adjust if single-select is chosen.

Acceptance Criteria

• A Workflow filter control is added to the Content Drive toolbar's filter row, next to the content-type and language filters.
• Opening the filter shows a two-column popover: workflow schemes on the left, steps of the focused scheme on the right.
• Selecting a scheme (no steps narrowed) filters content by all steps of that scheme; selecting specific steps narrows the result further.
• Selection cascades like the content-type filter: selecting a step selects its scheme (cascade up); deselecting the last step of a scheme drops the scheme (cascade down). (If single-select is chosen, this criterion is replaced by single-selection behavior.)
• Active selections render as chips with human-readable labels (scheme/step names), with an "all" suffix when a scheme is selected without step narrowing.
• The selection is persisted to the store via patchFilters and produces a correct Lucene query through buildContentDriveQuery (verified against the index field names).
• Selections round-trip through the URL (encodeFilters / decodeFilters) and are restored on reload.
• The filter is cleared by the toolbar's Clear all filters action and contributes to $hasFilters().
• All user-facing text uses i18n keys; interactive elements have data-testid; icon-only controls have aria-label.
• Component is covered by Jest + Spectator tests following the content-type filter's spec as a model.
• Decision recorded in the issue/PR on whether the filter is multi-select or single-select before merge.

Additional Context

• Existing related component (not a filter): dot-content-drive-workflow-actions handles bulk workflow actions — this new work is a filter, distinct from that.
• The content-type filter handles pagination, lazy loading, debounced search, and in-flight request cancellation. Evaluate which of these are needed for workflow schemes/steps (the scheme/step catalogs are typically small, so virtual scrolling / pagination may be unnecessary — keep it as simple as the data allows).