fix(content-types): reset field editor form state when creating a new field

[oidacra]

Summary

Fixes a bug in the content type editor where the field properties dialog leaked state (most visibly the Value textarea) from a previously saved field into a newly opened field dialog. Users would see the prior field's values prepopulated, the textarea would behave as uneditable, and Save would stay disabled until toggling an unrelated checkbox.

Closes #35434

Root cause

Two independent defects compounded to produce the visible behavior:

1. DotTextareaContentComponent.writeValue had a truthy guard (if (value)) that skipped empty/null/undefined values. When Reactive Forms called writeValue('') to reset the control, the Monaco editor's internal model kept the stale content from the previous field.

2. DynamicFieldPropertyDirective decided whether to recreate the dynamic inner component by comparing previousFieldId !== currentFieldId. Since every new field has id === null, switching between two new fields (e.g. Radio → Select) resulted in null !== null === false → the ValuesPropertyComponent (and its child Monaco editor) was reused rather than recreated, preserving its stale DOM.

Changes

• dot-textarea-content.component.ts — writeValue now writes the value directly (using ?? ''), so empty/null/undefined correctly reset the control.
• dynamic-field-property.directive.ts — compare the previous vs. current field reference instead of ids, so the inner component is recreated whenever the field instance changes.
• dot-textarea-content.component.spec.ts — new writeValue tests asserting the control resets for '', null, and undefined.

Acceptance criteria

• Creating a new field after saving any field type with a Value textarea opens a dialog with an empty Value textarea.
• Default Value, Hint, Name, and all boolean flags are reset for the new field.
• The Value textarea in the new-field dialog is immediately editable.
• The Save button follows its normal enable/disable rules (no sticky-disabled state from stale form state).
• Editing an existing field still loads that field's stored values (no regression in edit mode).
• Cancelling a new-field dialog and re-opening it does not resurrect stale values.
• Unit test added asserting writeValue correctly resets for empty/null/undefined.

Test plan

• Edit a content type.
• Add a Radio field with values like value|1 / value.2|2, save.
• Add a new Select field — the Value textarea must be empty and editable; Save must enable as soon as required fields are valid.
• Repeat for Radio → Radio, Select → Select, Select → Multi Select, Checkbox → Radio.
• Edit an existing saved field and confirm its stored values still load correctly.
• Open a new field dialog, type some values, Cancel, reopen — the form must be empty.

[claude]

Claude finished @oidacra's task in 2m 32s —— View job

---

PR Review

• Read changed files
• Analyze code for issues
• Post review

---

The fix is correct and the root cause analysis is accurate. Two issues worth flagging:

1. writeValue type signature is a lie

dot-textarea-content.component.ts:170

writeValue(value: string): void {
    this.value = value ?? '';
}

The implementation now handles null/undefined, but the parameter is typed string. The tests confirm the mismatch — they have to cast: component.writeValue(null as unknown as string). The ControlValueAccessor contract accepts any, so the fix works, but the declared type misleads callers. Should be string | null | undefined.

2. The isEqual outer guard can still swallow a recreation that shouldRecreate would have caught

dynamic-field-property.directive.ts:40-47

The outer ngOnChanges gate short-circuits on !isEqual(previousValue, currentValue). If two distinct new-field objects happen to be deeply equal (e.g. Radio → Radio where both share the same defaults and no variable diff yet), isEqual returns true, the whole body is skipped, and shouldRecreate is never reached. The reference-based fix in shouldRecreate only acts when the outer gate already opens.

In practice this edge case is rare because field switches produce a different clazz, but it's a pre-existing landmine this PR didn't close. Worth a follow-up or a comment in the code noting the dependency.

Everything else is clean.

[oidacra]

Added three unit tests in 13adbe9 covering the new reference-based shouldRecreate logic in DynamicFieldPropertyDirective:

1. Two new fields with id=null but different references → recreates the inner component.
2. The same field reference passed again → does not recreate.
3. Switching from a saved field to a new null-id field → recreates.

All 2109 tests pass.