Add REST and JSON:API support for responsive video styles

Problem/Motivation

Decoupled applications need responsive video delivery information, including ordered sources, breakpoint media queries, fallback selection, variant playback settings and posters.

Core REST and JSON:API can expose Media entities, but they do not expose the composition produced by Responsive Video Style. Exposing individual Video Styles alone would require clients to reconstruct Drupal's responsive ordering, fallback and poster-selection behavior.

The responsive integration should reuse the shared Video Style API infrastructure and existing responsive builder, preserving access checks, cacheability and provider-independent delivery.

Steps to reproduce

1. Create a file-video Media bundle and a published Media entity containing a video.
2. Create Video Styles and a Responsive Video Style using breakpoint mappings and fallback styles.
3. Enable JSON:API or configure a core REST GET resource for Media.
4. Request the Media entity.
5. Observe that the response does not contain the responsive source or variant composition needed to reproduce the configured playback behavior.

Proposed resolution

• Add an optional responsive_video_style_api submodule depending on Responsive Video Style and video_style_api, supporting both core REST JSON and JSON:API.
• Register a responsive style-family adapter with the shared API infrastructure and expose a read-only computed responsive_video_styles field on eligible Media bundles.
• Add explicit, default-off exposure settings to Responsive Video Styles, with a maximum of 32 exposed responsive styles.
• Reuse the existing responsive builder to preserve source ordering, breakpoint media queries, fallback deduplication, variant playback settings and poster precedence.
• Provide structured source metadata directly from the responsive builder, including URL, MIME type, codecs and media query, so API consumers do not need to parse HTML type attributes.
• Expose constituent delivery and processing states individually rather than reporting one aggregate ready state for a partially prepared composition.
• Carry source, constituent-style, responsive-style, breakpoint, poster and asset dependencies through the computed property's cacheability.
• Reuse the base API's exposure hooks and preparation queue. An exposed responsive style authorizes its constituent styles for that representation and preparation without requiring separate standalone exposure.
• Test both serialization formats, responsive composition, field ownership and independent submodule uninstall. Document frontend selection semantics and operational setup.

The initial scope is native file-video delivery. Provider-specific API implementations and frontend players are not required by this integration.

Remaining tasks

• Publish the implementation for review against 1.1.x alongside the Video Style API changes.
• Run project CI and verify clean installation with the required Video Style version.
• Review source/variant selection semantics, cacheability and independent uninstall behavior.
• Commit the reviewed changes.

User interface changes

When the submodule is enabled, Responsive Video Style add/edit forms gain an Expose through APIs checkbox, unchecked by default. Delete confirmation forms are unchanged. The 32-style exposure limit applies independently to responsive styles.

Existing responsive configuration controls and HTML playback behavior remain unchanged.

API changes

The submodule adds a read-only responsive_video_styles field using the shared versioned envelope. JSON:API exposes the envelope directly; core REST JSON retains its field-item wrapper.

Each responsive style record includes its identifier, supported state, rendering mode, strategy, playback settings, fallback text, sources, poster, variants and constituent deliveries.

Source-strategy clients preserve the supplied source order. Variant-strategy clients select the first matching non-null media query and use a fallback when none matches. Poster metadata and video/poster processing states remain available per constituent delivery.

ResponsiveVideoBuilder::buildDelivery() additionally supplies structured source records at the top level and on variants. Existing HTML source descriptors remain available.

No provider-specific REST resources or JSON:API normalizers are introduced.

Data model changes

• Add the responsive_video_style_api.exposed third-party setting to Responsive Video Style configuration, with configuration schema.
• Add a computed, non-stored Media field. No new Media content columns or asset registry tables are required.
• Reuse the base API's preparation settings and queue.
• Uninstall removes responsive API exposure settings and its computed field while retaining Responsive Video Styles and the independently enabled base API.