feat(design): show field errors from the API #535

Problem

The form controls of @elixir-cloud/design (input, textarea, select, multi-select, checkbox) have no invalid state and no place for an error message. Components that submit data to an API can therefore only show a general error when the API rejects a request, and each component would have to build its own field-error display.

Proposal

Generic support in @elixir-cloud/design, usable by every component that submits data, without validation rules in the components (the APIs keep the final say):

• Form controls get an invalid state and an error message: e.g. properties invalid and error (or an error slot), rendered under the control, with aria-invalid and aria-describedby set and the message announced (aria-live="polite").
• A small, server-agnostic utility for RFC 9457 problem details (application/problem+json): it parses the standard members (type, title, status, detail, instance) and the field errors in the form of the RFC's own example (errors[] with detail and pointer, a JSON Pointer as URI fragment like #/organization/url; plain pointers like /organization/url and parameter for request parameters accepted too), keeps extension members such as code available, and maps the errors to the component's fields by pointer. Errors whose pointer matches no field, and responses without errors or that aren't problem details at all, fall back to a general error, as today. It knows nothing about FOCA: FOCA apps will produce exactly this format (feat: report invalid fields in 400 responses foca#586), and any other RFC 9457 server works the same way.
• Docs: how components use both, with an example.
• Tests for the controls' states and the mapping (including unknown pointers and responses without errors).

The field-error display drafted in #510 (closed) can serve as a starting point.

Not blocked by elixir-cloud-aai/foca#586: this issue implements against a standard (RFC 9457), not against FOCA, and the form controls' error states don't depend on any server, so the work can start now. The two issues are linked only so that both use the same entry members (detail, pointer, parameter, code).