Add server-side field applicability hook (pluggable state providers)

Problem/Motivation

Add a minimal, internal hook point so ROP can skip enforcement when a field/subfield is not applicable on this submission. This is broader than client-side #states.

Potential provider examples (each may be a follow-up issue):

1. Media (core) source plugins
   1. Summary:
      Different media types expose different source fields (e.g., field_media_image vs field_media_oembed_video). The active source plugin can hide/disable the non-source fields. If ROP marks one of those fields required-on-publish globally, it should be skipped when the source makes it inapplicable.
   2. Provider signal:
      Inspect the entity’s media source plus the submitted input and return inactive for non-source fields.
2. Inline Entity Form (contrib)
   1. Summary:
      IEF toggles between “Reference existing” vs “Create new”. When referencing existing, the embedded create subform (and its fields) isn’t present. A provider can detect that path in the submitted input and mark the embedded fields inactive so ROP doesn’t complain about empty “create” fields on publish.
   2. Provider signal:
      Detect the “reference existing” path in the submission (no create subform data) and return inactive for the create-subform fields.
3. Field Permissions (contrib) / per-role field access
   1. Summary:
      Sites often hide or disable certain fields for specific roles (edit access denied). If an editor can’t edit a field that ROP marks required-on-publish, you typically want ROP to skip it (or at least not block them).
   2. Provider signal:
      If the current user lacks edit access for the field/subfield, return inactive so ROP doesn’t block publish.
4. Paragraphs behaviors / toggles (contrib)
   1. Summary:
      Many paragraph bundles include a boolean like “Show title?”. If unchecked, the “title” field is hidden via form alters (no CF involved). A provider can look at that toggle in the submitted input and mark field_title inactive for that paragraph delta.
   2. Provider signal:
      Read the per-delta toggle value from the submission and return inactive for the controlled field when the toggle disables it.
5. Form Mode–driven forms (Form Mode Manager, Display Suite form modes, etc.)
   1. Summary:
      Some workflows use a simplified “Publish” form mode that hides large sections. Those fields won’t be in the submission, but ROP would still enforce them unless told otherwise.
   2. Provider signal:
      Detect the active form mode (route context or a form-mode parameter saved in the request) and skip fields placed in hidden regions for that mode by returning inactive.
6. Commerce (contrib) product/variation specifics
   1. Summary:
      For non-shippable products, “weight”/“dimensions” widgets are removed/disabled; or certain attribute/price components don’t apply to a variation type. A provider can read the variation type (or “shippable” flag) and mark shipping-related fields inactive.
   2. Provider signal:
      Inspect the variation type/flags (e.g., shippable) and return inactive for fields not applicable to that type.
7. Content Translation / language-negotiated forms (core)
   1. Summary:
      With translation, some fields are non-translatable and intentionally disabled on the translation form. A provider can detect the current translation context and skip disabled/non-translatable fields on that form submission.
   2. Provider signal:
      Read translation context and field translatability/disabled state; return inactive for fields disabled or non-translatable in the current language form.
8. ECA / Rules-style form alters (contrib)
   1. Summary:
      Sites often use ECA/Rules to set #access/#disabled based on business logic. Those fields won’t appear in the input. A generic “input-presence” provider (like the shim but for top-level fields too) can mark them inactive.
   2. Provider signal:
      If a field is missing from the submitted input due to #access/#disabled logic, return inactive for that field.

Proposed resolution

Deliverables: tiny internal interface plus example provider docs; ship only conditional fields provider initially; others can be contrib/site code, or adopted for official support.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD