Align machine-name-like plugin fields between forms and typed configuration

Problem/Motivation

Follow-up to #3590374 (closed) and !683 (merged). An audit found 14 plugin fields using FormFieldMachineName, but their runtime contracts are not uniform and their typed-configuration constraints do not consistently match form validation.

The fields fall into three contract categories:

  1. strict machine names,
  2. token references, and
  3. token-replaced values, including render-array ][ paths.

This mismatch can reject supported values during typed-configuration validation, allow values that forms reject, or report requiredness differently depending on the validation path. In particular, the attached library/setting name is optional in the form while its schema applies NotBlank.

Proposed resolution

  • Inventory and classify all 14 FormFieldMachineName fields as strict machine names, token references, or token-replaced values.
  • Define the intended contract for each category, including render-array ][ paths.
  • Align typed-configuration constraints with form validation for every classified field.
  • Reconcile NotBlank constraints with form #required behavior.
  • Resolve the attached library/setting name discrepancy: optional in the form but NotBlank in schema.
  • Add data-driven kernel coverage for accepted and rejected values across all contract categories.

Acceptance criteria

  • Every audited field has one documented contract category.
  • Form and typed-configuration validation accept and reject the same values for each category.
  • Requiredness is consistent between #required and typed-configuration constraints.
  • Token references, token-replaced values, and documented render-array paths remain supported where intended.
  • Data-driven kernel tests cover all 14 fields and representative valid and invalid values.

User interface changes

None intended beyond making validation behavior consistent.

Data model changes

Typed-configuration constraints may change to match each field’s established contract.

AI-Generated: Yes (Used OpenCode to structure prior audit findings and draft this follow-up work item; Jürgen Haas requested and reviewed the scope.)