Define first-class rich text / markdown field strategy and editor variants

[horner]

Summary

Rename and reposition the current Kerebron-backed field documentation and product concept so it is no longer framed as a "custom" field type. Instead, present it as first-class rich text / markdown support with clear editor variants.

Problem

The current documentation places @esheet/field-kerebron under field-types/custom/kerebron, which implies the capability is niche or external rather than a supported rich text authoring option. That naming also does not reflect the likely product surface area:

• a standard rich text / markdown field for common authoring needs
• an expanded variant with advanced rendering and plugin support

This makes the feature harder to discover and creates ambiguity around how many editor modes should exist and what each mode supports.

Proposed direction

Define a first-class field strategy around rich text / markdown instead of a custom Kerebron label.

Naming

Evaluate and choose a supported field naming model such as:

• richtext
• markdown
• or both, if they represent distinct authoring experiences

Document the recommended naming and ensure package, schema, builder labels, and docs align with that decision.

Variants

Design at least two supported versions / modes:

1. Simple markdown / rich text
   • limited formatting surface
   • intended capabilities include bold, underline, bullets, and headings
2. Expanded rich content editor
   • advanced plugin-enabled mode
   • intended to support Mermaid, GenUIPlugin, CodePlugin, and MathPlugin

Plugin contract alignment

Review the plugin contract guidance referenced here and align the expanded mode with it:
https://github.com/mieweb/ui/blob/main/src/components/SuperChat/MAINTAINERS.md#render-plugin-contract-read-before-adding-a-plugin

Expected outcomes

• Rich text / markdown is treated as a supported field type rather than a custom add-on concept in docs and product terminology.
• The schema and builder UX clearly distinguish the simple and expanded authoring modes.
• The advanced mode has an explicit compatibility/design story for plugin-driven rendering.
• Migration/compatibility implications for the current richtext field and @esheet/field-kerebron package are documented.

Scope

• Audit current docs, schema naming, builder labels, and registration APIs related to the Kerebron-backed field.
• Propose the target information architecture for docs (for example, whether this moves out of custom/).
• Define the capabilities and constraints of the simple vs expanded modes.
• Identify implementation follow-ups needed for schema changes, renderer behavior, builder behavior, and package naming/registration.

Acceptance criteria

• A recommended naming model is documented for the field type(s).
• A simple mode is defined with limited markdown/rich text formatting.
• An expanded mode is defined with support goals for Mermaid, GenUIPlugin, CodePlugin, and MathPlugin.
• The design explicitly references and evaluates the plugin contract from mieweb/ui.
• Follow-up implementation tasks and migration considerations are captured.

Notes

Current docs page:

• apps/docs/docs/field-types/custom/kerebron.md

Current documented field type string:

• richtext

Current package:

• @esheet/field-kerebron

[redmine-bridge-mieweb]

Redmine Ticket: #158673 created from GitHub Issue