fix(fluentui): re-read a field's configuration when the rendered field changes (#335)

[phmatray]

Implements #335.

Closes #335.

#298/#308 fixed field-configuration staleness for MudBlazor; the Fluent UI adapter still has it — twelve components under FormCraft.ForFluentUI/Fields/ read their configuration in OnInitialized and never look again, so an instance re-parameterised with a different Context keeps rendering the previous field's settings.

Rather than copy the mechanism a second time, this moves it down: FieldConfigurationTracker and the OnFieldConfigurationChanged() hook go to FieldComponentBase in FormCraft core (they reference no UI type), both adapters inherit it, and MudBlazor's three local wirings — it needed one per component hierarchy — collapse to zero.

Executing the implementation plan task-by-task; the checklist below — and the plan on the issue — are ticked as each task lands. Opened as a draft — will be marked ready after the final task and a code-review pass.

Plan

• Task 1: Move the hook and tracker into core, re-point MudBlazor
• Task 2: Prove the Fluent adapter has the bug
• Task 3: Migrate the Fluent components
• Task 4: Document it

Code review

A high review of dev...HEAD found that the derived-state half of the hook's own contract had been under-applied across the Fluent components — and made the sharper point that the two adapters had already drifted on the very behaviour this PR moves to core to keep aligned, because the MudBlazor counterparts were solved correctly under #298. All fixed in bdf18bd:

• ⛔ The lookup reset was worse than the bug it replaced. Clearing _displayText in the hook was right for staleness and catastrophic alone: nothing else in the Fluent lookup repopulates it from the model. The MudBlazor lookup gets away with clearing because its OnParametersSet calls UpdateDisplayText() every render and repairs the blank on the same pass — the Fluent one has no such call, so a field with a perfectly good stored value rendered empty for ever. The hook now re-derives the text. Pinned by LookupField_Should_Keep_Displaying_Its_Value_After_A_Configuration_Swap, verified to fail against the clear-only version.
• The LOV kept _selectedItems across a field change — a subsequent pick appended to the previous field's rows, so the display read "old, old, new" and PublishSelectionAsync wrote the previous field's values into the new field's model property. The MudBlazor LOV clears the same list for the same reason (Field components cache their configuration at init, so a reused instance renders the previous field's settings #298).
• The lookup picker's _isOpen/_rows/_searchText survived a swap. _rows is a List<object>, so clicking a leftover row DynamicInvokes the new field's selectors against the old field's row object — an ArgumentException out of a click handler when the item types differ.
• Autocomplete kept _options and _selectedOption, so two fields whose values compare equal but whose labels differ left the previous field's label on screen.
• Removed a duplicated /// <inheritdoc /> and a comment referring to an OnInitialized that no longer exists.

Follow-ups

• A numeric bound that the new field does not declare is not dropped. Min/Max/Step reach FluentNumberInput through an @attributes splat, and Blazor retains a component parameter that a later render stops supplying — so omitting the key is not the same as unsetting it, even though FormCraft's dictionary is now correct. Expressing "unset" means FormCraft supplying Fluent's own defaults (int.MinValue) explicitly, i.e. binding the bounds as real parameters rather than splatting a dictionary. That is a change to how the Fluent numeric components are written, so NumericField_Should_Rebind_Its_Min_When_The_Configuration_Is_Swapped swaps one bound for another and the omission case is left for its own issue. The MudBlazor adapter has the same shape via MudTextField.Mask (noted under fix(mudblazor): re-read a field's configuration when the rendered field changes (#298) #308).
• The refresh suite covers the text, numeric and lookup components only. The review's own finding was that everything it caught lived in components the suite does not exercise. A parity suite driving a configuration swap across every field type in both adapters would turn that from a review catch into a build failure.