Add REST and JSON:API support for video styles

Problem/Motivation

Decoupled applications need structured video delivery information, including playable sources, poster metadata, playback settings and processing state. Core REST and JSON:API can expose Media and File entities, but they do not expose the delivery information produced by Video Style.

The 1.1.x development branch provides shared delivery and preparation services. An optional integration is needed to expose those services through core's existing serialization infrastructure, without requiring provider-specific REST resources or JSON:API normalizers.

API reads must preserve access checks and cacheability without triggering uploads, derivative preparation or provider HTTP requests. Sites that do not render videos through Drupal's HTML formatters also need an explicit way to prepare assets.

Steps to reproduce

1. Create a Media bundle using core's Video file source and a single-value File source field.
2. Create a Video Style and a published Media entity containing a video.
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 configured video style's delivery information.

Proposed resolution

• Add an optional video_style_api submodule supporting core REST JSON and JSON:API. Neither transport should be a required dependency.
• Add a read-only computed video_styles field to eligible file-video Media bundles, using the existing Media source resolver and delivery services.
• Add explicit, default-off API exposure settings to Video Styles. Return exposed styles in machine-ID order, with a maximum of 32 styles per family.
• Return a versioned envelope containing style identifiers, supported delivery state, source URLs, MIME types, codecs, poster metadata, playback settings and separate video/poster processing states.
• Use a cardinality-one field whose value property carries cacheability, including empty results. Preserve Media, source-field and File access checks, translations and revisions.
• Include asset and configuration dependencies in the computed property's cacheability so asynchronous completion invalidates cached JSON:API field normalizations without requiring a Media save.
• Keep reads free of asset preparation and provider HTTP requests. Honor JSON:API sparse fieldsets and keep REST field computation bounded.
• Add a bounded drush video-style:warm command and preparation queue, plus optional preparation on published default-revision Media saves. Incremental preparation defaults to off.
• Share protected-source policy through VideoPreparationInterface::isPermitted(). Skip policy refusals silently; retry transient preparation failures with delays and a bounded attempt count.
• Provide a tagged style-family integration contract so Responsive Video Style can reuse field definitions, exposure forms and preparation infrastructure.
• Cover serialization, access, cache invalidation, preparation policy and module lifecycle with automated tests, and document setup and operation.

The initial scope is native file-video delivery. Remote oEmbed video, provider-rendered players and frontend-specific cache invalidation are outside this issue.

Remaining tasks

• Publish the implementation for review against 1.1.x.
• Run project CI and verify installation, configuration and uninstall on a clean site.
• Review the public payload and operational documentation.
• Commit the reviewed changes.

User interface changes

When the submodule is enabled, Video Style add/edit forms gain an Expose through APIs checkbox, unchecked by default. The checkbox is not added to delete confirmation forms. Forms prevent exposing more than 32 styles.

Enabling API exposure does not automatically prepare existing assets. Initial warming is an explicit Drush operation.

API changes

The submodule adds a read-only video_styles field. JSON:API exposes its envelope directly:

{
  "video_styles": {
    "schema_version": 1,
    "styles": []
  }
}

Core REST JSON retains its normal field-item wrapper:

{
  "video_styles": [
    {
      "value": {
        "schema_version": 1,
        "styles": []
      }
    }
  ]
}

The submodule introduces StyleDeliveryInterface and the video_style_api.delivery service tag for additional style families. The unreleased preparation interface gains isPermitted(); prepare() applies the same policy.

Provider modules do not need transport-specific implementations. Existing provider delivery capabilities and shared delivery services remain the integration boundary.

Data model changes

• Add the video_style_api.exposed third-party setting to Video Style configuration, with configuration schema.
• Add video_style_api.settings with prepare_on_save defaulting to false.
• Add a computed, non-stored Media field and preparation queue items. No Media content columns or changes to the existing asset registry schema are required.
• Uninstall removes API exposure settings and pending API preparation jobs while retaining Video Styles and source assets.