SettingsFormSchema

El único punto que arma el `FormDefinition` de settings — el GET (Tarea 6) y el POST (Tarea 7) llaman a {@see self::definition()} para garantizar que ambos formen el MISMO form desde el MISMO schema (ADR#7: el schema sale siempre del `#[Tool]` vía `ToolScanner`, nunca fabricado a mano). Desde P5.4 acepta un `ToolRegistry` opcional: sin argumento (BC del GET) sigue armando su propio `ToolRegistry`/`NullLogger` desechables SOLO para escanear los atributos `#[Tool]`/`#[Param]` de {@see SettingsTool} — ese registry nunca ejecuta `settings_update`, así que un logger nulo es correcto: no hay nada que loggear en un escaneo puro de reflexión. Con un registry dado (el REAL de {@see SettingsToolRegistry}, logger PSR-3 del host), reusa ESE registry — el mismo que sirve `call()` — en vez de escanear dos veces.

public static function definition(?Milpa\ToolRuntime\ToolRegistry $registry = null): Milpa\Live\Schema\FormDefinition

El `FormDefinition` de settings, escaneado del `#[Tool]` real — nunca fabricado a mano. Sin argumento: arma el throwaway scan-only de siempre (BC — el GET actual sigue llamándolo así). Con `$registry`: usa el registry REAL de P5.4 (el mismo que sirve `call()`).

Parameters