Expose displayOn on a dedicated WebformElementDisplayOnBase

Problem/Motivation

The generated WebformElementMarkupBase interface bundles two unrelated fields: markup (the element's authored HTML) and displayOn (whether the element renders on the form, the submission view, both, or nowhere). WebformSchemaBuilder assigns this interface to every element whose plugin extends WebformMarkupBase.

Several of those elements are display-only and never populate #markup — they carry their content elsewhere or have none at all. They are pulled into the interface only for displayOn, yet they also inherit a markup field that is structurally always null:

• WebformElementWebformMessage — body lives in #message_message, exposed as messageBody.
• WebformElementLabel
• WebformElementWebformMore
• WebformElementView — identified by name / displayId / arguments.

A frontend introspecting the schema sees a markup field on these types and cannot tell from the schema that it will only ever return null. The conflation also misrepresents the domain: in Webform itself, "displays on" is a separate WebformElementDisplayOnInterface, while markup content is the concern of WebformMarkupBase. The GraphQL schema flattened the two into one interface.

Steps to reproduce

Query markup on a webform_message (or label / webform_more) element via form { elements { ... on WebformElementMarkupBase { markup } } }. The field resolves to null for every such element, with no schema signal that it must.

Proposed resolution

Separate the two concerns, mirroring Webform's own split:

• Add a WebformElementDisplayOnBase interface carrying only displayOn, assigned to every element whose plugin implements WebformElementDisplayOnInterface.
• Narrow WebformElementMarkupBase to the markup field, assigned only to elements that render authored HTML markup (webform_markup; processed_text keeps its dedicated markup resolver).
• As a result, WebformElementWebformMessage, WebformElementLabel, WebformElementWebformMore and WebformElementView expose displayOn without a markup field.

This is a follow-up to the specialized-elements work in #3599006: Specialized elements; message exposure surfaced the wart but it predates that issue for label / webform_more / view.

Remaining tasks

• Add the WebformElementDisplayOnBase interface in WebformSchemaBuilder and gate it on WebformElementDisplayOnInterface; narrow WebformElementMarkupBase to markup.
• Move the displayOn resolver wiring to the new interface in WebformExtension; keep the markup resolver only where markup is populated.
• Update the per-element tests and the element fixtures so the affected types no longer assert a markup field.
• Write a change record for the removed markup fields and the interface change.

API changes

New WebformElementDisplayOnBase interface exposing displayOn (additive).

Breaking: WebformElementMarkupBase no longer declares displayOn, and the markup field is removed from WebformElementWebformMessage, WebformElementLabel, WebformElementWebformMore and WebformElementView. Consumers that selected markup on those types (always null) or relied on displayOn through WebformElementMarkupBase must update their queries. Needs a change record.

Release notes snippet

Display-only elements (message, label, more, view) no longer expose an always-null markup field; displayOn moved to a dedicated WebformElementDisplayOnBase interface.