Expose View Controls Metadata and Empty-State Content in `lupus_decoupled_views` Custom Element Payload

Summary
This proposal adds first-class frontend metadata to `lupus_decoupled_views` custom-element output so decoupled clients can build robust, native filter/sort/pagination UX without project-specific processors.

Problem
Today, custom-element view payloads include rows, title, and pager, but typically do not expose:

- Exposed filter definitions (labels, identifiers, options, submitted values)
- Exposed sort definitions (sort field, order options, submitted values)
- Empty-state text/markup configured in View "No results behavior"

As a result, decoupled frontends must:

- Reconstruct View form semantics manually, or
- Add custom per-project Drupal processors to extract this data

This creates duplicated logic and inconsistent API contracts across projects.

Proposed Change
In `lupus_decoupled_views` display payload generation (`CustomElementsViewsDisplayTrait::buildCustomElement`), add attributes:

- `exposed_filters`
- `exposed_sorts`
- `no_results`

Data sources
- Exposed handlers from the View executable (filter/sort handlers + exposed input)
- Existing pager plugin data (already present)
- Empty-state content from rendered `#empty` and/or configured display empty handlers

Suggested payload shape

json
{
  "viewId": "podcast",
  "displayId": "block_1",
  "exposedFilters": [
    {
      "label": "Content type",
      "identifier": "type",
      "queryParamName": "type",
      "required": false,
      "multiple": false,
      "options": {
        "article": "Article",
        "page": "Page"
      },
      "submittedValues": []
    }
  ],
  "exposedSorts": [
    {
      "label": "Title",
      "fieldIdentifier": "title",
      "queryParamSortBy": "sort_by",
      "queryParamSortOrder": "sort_order",
      "sortByValue": "title",
      "sortOrderOptions": {
        "asc": "Sort ascending",
        "desc": "Sort descending"
      },
      "submittedOrder": "asc"
    }
  ],
  "pager": {
    "current": 0,
    "totalPages": 2
  },
  "noResults": "<p>No matching content found.</p>"
}

Why this is valuable
1) Better decoupled UX out of the box
Frontends can immediately render:
- Filter controls
- Sort controls
- Correct query param wiring
- Empty-state messaging from Drupal-authored content

2) Less custom code in consuming projects
Projects no longer need ad-hoc processors for common View concerns, reducing maintenance and drift.

3) Stronger API contract for Views in decoupled mode
This aligns the CE payload with how Views are configured in Drupal admin and makes integration predictable.

4) Backward compatible
Existing consumers that only use rows/pager continue to work. New attributes are additive.

Test Coverage Requested
Add/extend functional tests in `lupus_decoupled_views` to validate:

- Exposed filters metadata present and normalized
- Exposed sorts metadata present and normalized
- Empty-state message is present when result set is empty
- Payload remains valid when no exposed handlers are configured

Optional Follow-up
- Document these attributes in module README/API docs
- Add an alter hook or display option to enable/disable metadata blocks if maintainers prefer opt-in behavior

Frontend Impact
This significantly improves frontend filtering/sorting ergonomics in Nuxt/React/etc. by turning Views configuration into consumable runtime metadata rather than requiring custom parsing or duplicated definitions.