Announce the webform handler's blocked-option notice, type the payment_lapsed action, and wait on a real signal in a browser test

Three defects found while auditing the module file by file. They are unrelated to one another and each is small, so they are grouped here rather than split across three issues.

1. The webform handler's "why this option is off" notice is invisible to a screen reader

OrchestraInteractionHandler::buildConfigurationForm() concatenates a raw div carrying the classes messages messages--warning into the #suffix of the "Return to the workflow after submit" checkbox. Those classes are Claro's and Olivero's, not core's: core's own status-messages.html.twig emits no classes at all, and carries instead the region's role, its aria-label and a visually-hidden heading. So the hand-built div gets none of the accessibility, and under an admin theme that is neither Claro nor Olivero it is not even styled as a warning.

The checkbox beside it is disabled, so that sentence is the only way to learn why the option cannot be turned on, which is exactly the case that has to be announced rather than only shown.

2. The payment_lapsed timeout action declares no settings schema type

A timeout's settings key, and a timer rung's, is typed orchestra.timeout_action.[%parent.action], and there is no wildcard behind it. The kernel therefore declares a type for its own settings-less action and says why in place: orchestra.timeout_action.unclaim is "typed so a timer that emits empty unclaim settings passes strict schema". orchestra_payment ships payment_lapsed and declares none, so the first path that emits an empty settings map for it reaches a type that is not there.

3. A browser test waits on a selector its own theme never emits

CompositeConditionTest follows each Save with a wait on .messages, .messages--status. The class runs in stark, and core ships system.theme with an empty admin theme, so an admin route falls back to stark, whose status-messages markup carries no messages class. The selector can never match: the wait runs to its ten-second default and returns NULL, which neither call checks. The assertion after it then reads the saved workflow separated from the Save click by a fixed sleep rather than by the page having come back, and the class spends twenty seconds a run waiting for nothing.

Proposed resolution

• Render the handler's notice through #theme: status_messages with #status_headings, the shape every inline caller in core uses and the one that supplies the label and the heading.
• Declare orchestra.timeout_action.payment_lapsed as an empty mapping, beside the resolver types already in that file.
• Wait for the sentence the form actually posts, and assert the wait rather than discarding it.

Both strings the change adds are translated in the catalog of the project that writes them. "Warning message" takes core's own French, so the one string table locale keeps cannot hold two answers for it.

Tests

• ExampleConfigSchemaTest gains an assertion that every timeout action orchestra_payment provides declares a schema type, naming the set so it cannot pass by finding nothing to check. It fails against the unpatched schema and passes with the fix.
• The covering functional test asserted messages messages--warning, which passed only because the markup was hand-built. It now asserts, of one region, the aria-label, the visually-hidden heading and the sentence. It asserts neither the role, which core 12 changed from contentinfo to alert, nor the theme class, which is absent under the theme the test runs in.
• The two browser waits become assertions, so a save that never lands fails where it happened rather than further down as a condition tree that does not match.

Considered and not done here

Nineteen #markup values hand a bare sentence to whatever element carries them, which is almost always a container, so the text belongs to no block. A revision of this issue put them back on the project's own '<p>' . $this->t(...) . '</p>' shape with a standing assertion over every shipped class. Where a rendered value's markup belongs is a question about the templates that print it, so it is answered there rather than by wrapping each value in the class that hands it over; that revision is reverted whole.

User interface changes

The notice on the Webform handler settings form is rendered as a real status message, so it is announced to assistive technology and picks up the admin theme's own message styling. Its wording is unchanged.

AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)