Show schema-defined field help text in the content editor

[virafb]

Problem

Database-backed collection fields have labels but no first-class help text in the content editor. On long operational forms, a label cannot explain where a value appears on the public site, what format is expected, or what will break if it is cleared.

EmDash already has a FieldHelpLabel component and code-first field builders expose helpText, but the dynamic schema path does not carry that capability:

• Field, CreateFieldInput, and UpdateFieldInput have no description/help-text property.
• the create/update schema APIs strip a top-level field description;
• the admin manifest’s field descriptor has no help text;
• the content editor therefore has nothing generic to render.

A local EmDash 0.32.0 baseline verified this through the public schema API and the real content editor.

Proposed solution

Add optional, schema-defined field guidance end to end:

1. Add a nullable description or helpText property to the registered field model, migration, seed format, create/update APIs, client types, and admin manifest.
2. Add the property to the field editor UI.
3. Render it consistently beside or immediately below the field label in the content editor. A visible short line is preferable for operational instructions; an info tooltip can remain available for longer text.
4. Extend repeater subfield definitions with the same optional property so row inputs can explain their format.
5. Keep it optional and backward compatible; existing fields render unchanged.

If avoiding a migration is a priority, field.options.helpText could carry the first version because widget options already round-trip arbitrary keys. A typed field property seems clearer long-term because this is common metadata rather than widget-specific configuration.

Acceptance tests

• seed/export/apply round-trips field and repeater-subfield guidance;
• create and update schema APIs preserve it;
• content editor renders it for scalar, media, rich-text, and repeater fields;
• schema editor can add, change, and clear it;
• strings are localized and layout remains RTL-safe.

Motivation

This came from testing a real schema-backed editor with dozens of fields and repeated rows. Editors need enough context to edit words safely without being granted schema or layout control.