…anges

OnSelectedValuesChangedAsync handles only programmatic SelectedValues parameter
changes (user selection goes through SelectOption). It was firing
FieldChanged(_selectedValues) for any change after the first render, so an
async-loaded SelectedValues fired FieldChanged without user interaction; for
MudSelect<string> multiselect, the typeof(T)==string branch also ran
SetValueAndUpdateTextAsync outside the suppression block, firing FieldChanged
even on initial load.

Wrap the whole handler in SuppressInteractionEffectsWhileAsync and gate the
explicit FieldChanged on `wasTouched && !IsChildOriginatedChange` (mirroring
MudBaseInput.OnValueParameterChangedAsync), so an initial or async-loaded
selection on an untouched select no longer fires FieldChanged while an external
change to an already-touched select still notifies the form.

Extends the repro component with a MultiSelection @bind-SelectedValues case so
the existing initial-load and async-load tests cover this path.

Reverts the MudTextField.SetTextAsync suppression: SetTextAsync once again marks
the field touched and fires FieldChanged. MudBlazor#12997 is a deliberate behavior change
(programmatic SetTextAsync should not touch) that also changes an existing test's
expectations, so it should be decided and reviewed on its own rather than riding
along with the MudBlazor#13246/MudBlazor#13064 regression fixes.

Restores FieldChangedEventShouldTrigger to use SetTextAsync, removes the
SetTextAsyncDoesNotTouchOrFireFieldChanged test, and drops the MudBlazor#12997 reference
from the suppression-flag comment. The flag/helper itself stays - it is what the
regression and picker fixes use.

The suppression mechanism was over-commented: a variant of "this is a
programmatic sync, don't touch (MudBlazor#13246, MudBlazor#13064)" was repeated at nearly every
wrap and gate site, duplicating what the _suppressInteractionEffects flag and
SuppressInteractionEffectsWhileAsync helper names already convey, and scattering
issue numbers that would rot.

Keep one canonical explanation on the flag declaration (the single place issue
refs live) plus a concise helper summary, and keep the two genuinely non-obvious
comments that prevent reintroducing a bug: MudTimePicker.SubmitAsync committing
directly instead of through the suppressed setter, and MudSelect's wasTouched
FieldChanged gate. Remove the rest. No behavior change.

… ambient flag

An adversarial review found a Blazor Server re-entrancy hole: the date/time
picker value-property setters and MudBaseInput.ForceRender ran the suppression
wrapper fire-and-forget (SuppressInteractionEffectsWhileAsync(...).CatchAndLog()),
so the instance _suppressInteractionEffects flag stayed set across the awaits
inside the sync (DateChanged.InvokeAsync, async BeginValidateAsync). On a Server
circuit a concurrent user interaction landing in that window - e.g. a calendar
pick, whose commit path has no independent Touched write - would read the leaked
flag and silently skip Touched + FieldChanged.

Thread the suppression explicitly: SetDateAsync/SetTimeAsync/SetDateRangeAsync
take a suppressInteraction parameter that the value-property setters pass as true,
while user-commit paths (calendar/clock pick, text input, Submit) use the default
false. Two interleaved operations on the same instance can no longer observe each
other's intent, so the leak is eliminated by construction. ForceRender reverts to
its pre-PR behavior (no suppression), removing the last fire-and-forget site.

Also corrects the now-accurate comment on _suppressInteractionEffects (it is only
toggled around awaited parameter-change handlers) and drops a dead guard in
OnTextParameterChangedAsync. The flag now remains only on awaited paths.

Verified: full unit suite (5160 passing) plus interactive WASM runtime checks
(async-loaded values stay untouched / fire no FieldChanged; user calendar pick
touches and fires FieldChanged).