Say where a plugin subform's validation error goes, so the next one does not name it

Problem/Motivation

A plugin's validateConfigurationForm() is handed a SubformState by whatever host embeds it. Reporting a refusal with $form_state->setErrorByName() there builds the error name out of the subform's #array_parents, while an error finds its field through that element's #parents. Under the classic modeler the two differ, because it renders every node beneath a structure wrapper that the submitted path does not carry, so a named error belongs to no element on the page: the control is never marked, and the collapsed section holding it never opens, since OrchestraCmForm opens a section by matching the same key.

That is the bug #3624283 fixed. This issue is about why it happened three times.

Every plugin that has ever reported a refusal from a subform got it wrong: EntityInteraction (form_operation) and WebformInteraction (mode and context_display) all shipped naming the error, and the Groups audience added in #3624219 was written the same way before an audit caught it. Two of the three carried a comment asserting the opposite, that the host "prefixes the subform's own place in the form for us" - true of what it builds, false of what the error matcher reads.

The rule is nowhere a plugin author would look. docs/extending.md is the page that explains how to write an audience, a condition, a task type and their settings forms, and it does not mention setError, validateConfigurationForm or #parents once. The only statements of the rule are three copies of the same seven-line comment, sitting inside the three plugins that already learned it.

Proposed resolution

State it once, where somebody about to write a settings form is already reading. A short passage in docs/extending.md: set a validation error on the element, never by name, because the key an error is found by is the element's #parents and a subform's name is built from its render path, which the modeler nests one level deeper.

$form_state->setError($form['mode'], $message);   // finds the field
$form_state->setErrorByName('mode', $message);    // reaches nothing

Then trim the three in-code comments to a sentence pointing at it, so the explanation has one home and cannot go stale in two of three places.

Remaining tasks

• Add the passage to docs/extending.md.
• Shorten the comments in EntityInteraction and WebformInteraction (both sites) and in the Groups audience.

User interface changes

None. The behavior this documents is already fixed; this is about the next plugin, not the existing ones.

AI-Generated: Yes (Claude Code was used to help draft this issue summary. The recurrence it describes was found while auditing #3624219 and fixing #3624283; no change has been written for this issue yet.)