Builder-Palette-Registrierung für Custom-Feldtypen (FieldTypeRegistry)

## Kontext

MForm 10.0 bietet mit `MForm::registerFieldType()` / `FieldTypeInterface` eine saubere Erweiterungs-API für Fremd-Addons, um eigene Feldtypen zu registrieren (siehe [API-Referenz](https://github.com/FriendsOfREDAXO/mform/blob/main/docs/13_api_reference.md#eigene-feldtypen-registry-ab-100), Roadmap nennt `relation_select`, `linkmap`, `mediaplace` als vorgesehene erste Nutzer).

Ich habe das gerade für das [a11y_datetime_addon](https://github.com/FriendsOfREDAXO/a11y_datetime_addon) umgesetzt (`MFormFieldType` implementiert `FieldTypeInterface`, registriert in dessen `boot.php`). Funktioniert einwandfrei über `addCustomField('a11y_datetime', ...)` — sowohl im klassischen Formular als auch im Flex-Repeater.

## Problem

Der visuelle Formbuilder (`pages/formbuilder.php`) hat eine **fest verdrahtete** Palette-Liste (`

` mit statischen `
• `-Einträgen). Es gibt keine Möglichkeit, über `FieldTypeRegistry` registrierte Fremd-Feldtypen dort erscheinen zu lassen — sie sind nur programmatisch über `addCustomField()` im Modul-Code nutzbar, tauchen aber nicht als Drag&Drop-Baustein im Builder auf.

  ## Vorschlag

  `FieldTypeRegistry::register()` (bzw. eine neue begleitende Methode) könnte optional Palette-Metadaten entgegennehmen, z. B.:

  ```php
  MForm::registerFieldType('a11y_datetime', A11yDatetimeFieldType::class, [
  'label' => 'a11y_datetime Picker',
  'icon' => 'fa-calendar', // optional, Fallback-Icon falls keins angegeben
  'group' => 'community', // z.B. eigene Palette-Sektion "Community-Feldtypen" statt in die feste Liste zu mischen
  ]);
  ```

  `formbuilder.php` würde dann zusätzlich zur statischen Liste eine dynamische Sektion rendern (z. B. `FieldTypeRegistry::paletteEntries()`), die alle registrierten Typen mit Palette-Metadaten auflistet — ähnlich der bereits vorhandenen Gruppierung "Felder" / "Wrapper".

  Rückwärtskompatibel: Feldtypen, die weiterhin ohne Palette-Metadaten registrieren, funktionieren wie bisher rein programmatisch, erscheinen nur nicht im Builder.

  ## Warum das lohnt

  Ohne das bleibt die Registry-API für Fremd-Addons ein reiner Code-only-Weg — Redakteure, die Module über den Formbuilder statt per Hand-PHP bauen, können registrierte Custom-Feldtypen gar nicht nutzen, was einen Großteil des Komfortgewinns der neuen API wieder aufhebt.

  Gerne bereit, das auch selbst als PR umzusetzen, falls das Design so grob passt.

Start with pages/formbuilder.php and the FieldTypeRegistry registration API described in docs/13_api_reference.md. Define how optional palette metadata is stored and how registered entries are rendered alongside the existing static palette, while keeping registrations without metadata unchanged. Done means a registered custom field type appears as a usable builder item and remains available through addCustomField().

Written by the indexing model from the issue text.