Switch context item text fields to string_long for clean MDXEditor integration
## Summary
Follow up to:
#3586170
Convert the context item text fields (`content`, `purpose`, `description`) from `text_long` to `string_long` and remove the forced-plain_text workaround. This is a storage schema change, so it must land **before rc1** while the schema is still cheap to change.
## Problem
These fields are `text_long`, whose `text_textarea` widget always pulls in Drupal's format selector + filter/editor pipeline. On Drupal CMS that
defaults to the CKEditor-backed "Content" format, fighting our
markdown-via-MDXEditor authoring.
To work around this, `AiContextItemForm::afterBuildForcePlainText()`
currently:
- forces `format` to `plain_text` and hides the format selector,
- strips CKEditor5 libraries,
- filters `#attached` libraries/drupalSettings to keep only MDXEditor.
This is brittle: it fights the field type rather than configuring it, and it relies on string-matching library names.
## Why string_long is the right model
Nothing in the module consumes the `text_long` `format` column:
- Editing: MDXEditor (attached via `data-mdxeditor`).
- Display: `MarkdownFormatter` (CommonMark → HTML, ignores `format`).
- LLM output: `AiContextRenderer` passes raw markdown text through.
MDXEditor is designed to attach to a plain `#type => 'textarea'`
(see ai module docs: ui/mdxeditor), which `string_long`'s `string_textarea` widget provides natively — no format column, no format selector, no CKEditor. So `string_long` removes the unused `format` column honestly instead of suppressing it at runtime.
## Plan (Option A)
1. **Entity** (`AiContextItem::baseFieldDefinitions()`): change `content`,
`purpose`, `description` from `text_long` to `string_long`; drop the
`allowed_formats` widget settings and the `format` default values.
2. **Form** (`AiContextItemForm`): remove `afterBuildForcePlainText()` and
the library/drupalSettings stripping; keep the `data-mdxeditor` attach.
The widget becomes a plain `string_textarea`.
3. **Display formatter** (`MarkdownFormatter`): already declares
`string_long` in `field_types`; confirm the view display still uses it.
4. **Diff** (`DiffHooks`): switch the three fields from
`text_field_diff_builder` to `core_field_diff_builder` and drop the
`compare_format` setting (string_long has no format).
5. **Update hook** (`ai_context.install`): migrate storage from `text_long`
to `string_long` — preserve the `value` column, drop the `format`
column — for any existing installs.
6. **Config**: update any exported entity form/view display config to the
new field type.
## Rejected alternative (Option B)
Keep `text_long` but use a dedicated no-editor text format restricted via `allowed_formats`. Avoids the schema change but keeps the unused `format` column and still needs the single-option selector hidden. Rejected because `string_long` is the honest model and the schema change is cheap pre-rc1.
Note: earlier "add a `markdown` filter format / use the `format` column"
suggestions are also rejected — they re-engage the CKEditor pipeline that MDXEditor is meant to bypass.
## Acceptance criteria
- [ ] Sense check this is the right approach to the problem
- [ ] `content`, `purpose`, `description` are `string_long`.
- [ ] MDXEditor loads on these fields with no CKEditor/format-selector leakage.
- [ ] `afterBuildForcePlainText()` and the library/drupalSettings stripping are
removed.
- [ ] Existing context items keep their markdown content intact (verified by an update-hook test).
- [ ] Display (`MarkdownFormatter`), LLM output (`AiContextRenderer`), and
revision diff behavior are unchanged.
- [ ] `./lint.sh` passes; unit/kernel/functional tests updated and green.
## Priority
Pre-rc1. Storage schema change — must land before the schema is frozen.
## AI usage
- [x] AI assisted issue
- [x] AI generated code
issue