ui: a line-item dialog marks its required fields and names the one the server refused (#7062)

[delchev]

Fixes #7062

What was wrong

The generated Add line dialog of a document said nothing about which values were mandatory before the save, and nothing about which one was refused after it.

Filling a line but leaving a required: true relation empty, the server answers a plain 400 {"message":"The 'TaxRate' property is required"} - correct and specific. The dialog showed the generic banner "The request could not be completed. Please review your input.", marked no column, and carried no required marker on any field: the user was told the wrong field was wrong and never told which one was right.

Two halves, both in the dialog

The marker. editColumns[].required was already in the detail registration and simply never rendered - the dialog's label was a bare x-text, so only the header form marked its required fields. All three item dialogs (power document, personal, partner) now carry the same * the header form does.

The mapping. The generated controllers state a rejection in prose, naming the property in single quotes, as a plain 400 rather than a structured 422 with errorCauses - so apiErrors.messageFor had nothing but the status to work from and printed the BadRequest catalog line. Two shared helpers now read that prose:

• apiErrors.namedProperty(err, knownNames) - the first quoted token that is a field of the form in hand. That gate is what keeps the developer-facing rule intact: an arbitrary 400 (a stack-trace reason, an internal identifier) names nothing known and still falls back to the catalog message.
• apiErrors.messageWithLabels(err, labels) - the same message in the surface's own labels: "The 'Tax Rate' property is required".

The dialog marks that column with aria-invalid - which is what Harmonia actually colours the label and the border from (has-[[aria-invalid=true]]:text-negative on x-h-field, aria-invalid:border-negative on the control) - and shows the message in its banner. baseFormPage.applyApiError does the same for every generated header form, so both surfaces answer a named rejection alike instead of only the 422 path being wired.

Scope note

I could not reproduce why Name specifically turned red in the report: nothing in the templates binds an error to it, and Harmonia colours a field only from aria-invalid or a native :user-invalid, so that was most likely a stray native validity on that input rather than the error mapping. What this change guarantees is that the column the server named is the one explicitly marked; nothing else in the dialog is marked by generation.

Verification

IntentEmissionCoverageIT extended with assertions on the emitted marker, the aria-invalid binding and the mapping, anchored on the Roster document (its line's day is required: true) - green, 1/1, 136.7 s, on top of a full quick-build reactor. formatter:validate clean on the touched module.