feat: Add WinUI-shaped input validation - #24838

DependencyPropertyDescriptor.Parse redirects a parenthesized binding path to the
attached property's owner type, but only the originally queried type's static
constructor had been forced. When the owner had not been initialized yet its
property was not registered, the lookup missed, and the null was negatively
cached -- so a binding to an attached path read the initial value once and never
subscribed to changes. Affects any `{Binding (Owner.Property)}`, Canvas.Left
included.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Implements steps 1-3 of specs/059-input-validation:

- ValidationPropertyAttribute declares which dependency property of a control
  type is its input, resolved through the existing DependencyProperty.GetProperty
  and cached per type (negative answers included) in a ConditionalWeakTable, so
  the cache does not pin collectible AssemblyLoadContexts.
- FeatureConfiguration.Validation hosts the app-wide switch and that lookup.
- Validation exposes IsEnabled / HasErrors / Errors as attached properties, the
  read model an application binds its own error markup to.

Inert until the transport layer populates them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Implements step 4 of specs/059-input-validation.

Participation is decided where both SetBindingInternal overloads converge, which
is also the only place the owner and the fresh BindingExpression are both in
hand; a ResourceBinding never reaches it. Resolution is separate and runs on
BindingExpression.OnValueChanged, the funnel every path re-resolution passes
through -- including the initial one, which is what survives a source whose
value already equals the target property default.

The subscription is keyed on the control rather than on the expression, since a
rebound property replaces its expression with no notification. ErrorsChanged is
subscribed weakly so a view model cannot root the control, and an off-thread
raise hops to the dispatcher.

Two hazards the spec did not cover are handled here: the attached property is
usually set after the binding in generated XAML, so registration cannot be gated
on it and the changed callback pulls the current expression instead; and binding
removal is silent, so teardown hooks ClearBinding, which covers both rebinding
and ClearValue.

Leaf resolution reads the update sources of a compiled binding, not just the
binding path -- the latter stays empty for x:Bind, which would otherwise have
reproduced microsoft-ui-xaml#4642 in reverse.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Implements step 5 of specs/059-input-validation. TextBox, PasswordBox, NumberBox,
AutoSuggestBox, ToggleSwitch, ToggleButton (and so CheckBox and RadioButton),
Slider and ComboBox declare their input and re-broadcast the errors of their
source. RichEditBox is left out: its content is an ITextDocument with no
dependency property to bind.

The attribute sits on the leaf type, never on RangeBase or Selector, which is
what keeps ProgressBar and FlipView out -- the case a per-dependency-property
flag could not have expressed.

ErrorChanged is backed by one shared attached property rather than per-control
storage, kept apart from the subscription state so handlers survive a rebind.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Shows the whole opt-in: a view model implementing INotifyDataErrorInfo, one
attached property on the control, and the error text rendered by the markup of
the application through its own converters -- this slice ships none.

Enables the feature in SamplesApp startup, which is also where a real
application would set it, and covers the compiled-binding path with a unit test.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The spec renames the FeatureConfiguration class and the attribute to carry an
InputValidation prefix, so that they no longer read as one type in two places
next to the Validation attached-property owner.

Also records in the spec what implementation corrected about it: the three
lifecycle hazards that do not hold, the compiled-binding leaf, the attached
property lookup bug that had to be fixed first, and the resolutions of Q1, Q3,
Q5, Q8, Q9 and Q11.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The weakly subscribed ErrorsChanged handler is the part of the design most
likely to regress silently, and a strong handler would let one long-lived view
model root every control bound to it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Asserts the ten members are protected rather than internal, so an
accidental narrowing fails with a named member instead of a compile error
from another project.

It proves the modifier, not the sufficiency of the surface: a member left
internal elsewhere would keep this green while a third-party control
still could not be written. The proof of sufficiency is that
Uno.UI.Tests.ViewLibrary compiles at all, so do not delete the control
there believing this covers it. The names are spelled out rather than
taken from nameof, since a protected member is not accessible to a type
that does not derive from Control -- which is the point of the guard.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

059 kept describing a Validation class that no longer exists. Section 4.1
gets a superseded banner rather than a rewrite -- 10b's decisions are
written against it, so deleting it would strand them -- and 10b gains D3
for the fold onto Control, including the third-party defect the old shape
hid and the internal FrameworkPropertyMetadata overload found while
proving it fixed. The owner-type, ordering and read-only notes named
members that were renamed or removed.

060 claimed three framework triggers where two of them were the same
callback, and still placed the shared statics on Validation and
ErrorTemplate on an attached property.

The historical sections of both specs keep their original wording: 10b is
the mechanism that supersedes them, as it already was.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UpdateValidationStatesInternal now applies or leaves the validation
state groups, so OnValidationModeChanged no longer branches on
participation only for UpdateValidationStates to re-test it.

The template-application hook in FrameworkElement therefore leaves the
groups too, closing the mirror of the timing gap it was added for: a
control whose mode went to Disabled before its template was realized
had its GoToState return false with nothing left to re-apply it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The ObservableValidator of the MVVM Toolkit reports ValidationResult
rather than strings, and only its ToString reaches InputValidationError.

Realize the template's ErrorPresenter on the first error and present the
ErrorTemplate in it (inline, or in the DefaultCompactErrorIconTemplate
tooltip). Wired to HasValidationErrors, InputValidationMode and a new
protected OnErrorTemplateChanged, plus template application (Uno-only).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Template realization applies the disabled branch of
EnsureValidationVisuals, so a non-participating control lands in
ValidationDisabled while its error group stays unset.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Only TextBox, PasswordBox, AutoSuggestBox and ComboBox take part in
input validation, as in WinUI's CControl type switches. NumberBox,
Slider, ToggleSwitch and ToggleButton no longer implement
IInputValidationControl, and ComboBox validates Text rather than
SelectedItem, matching its WinUI [InputProperty].

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

A non-editable ComboBox is bound on SelectedItem, so validating Text
left the common setup without errors. ComboBox validates SelectedItem
again; the app-wide map and a shadowing subclass remain the routes to
validate SelectedIndex or another property instead.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The boxing analyzer (UnoInternal0002) that landed on master flags the
default(bool) metadata of the four per-control HasValidationErrors
registrations. Use BoolBoxes.False, as the rest of Uno.UI does.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The WinAppSDK sync generator keeps a placeholder for a hand-implemented
type, with its members skipped, and fails the check when it is missing.
This is the file it regenerates.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

WinAppSDK exposes no public input validation surface: neither
InputValidationError nor TextBox.InputValidationMode exist there, so
the sample cannot compile against it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The handlers and the subscription lived in attached dependency properties,
a leftover from when a separate Validation class owned them. A single
lazily-created state object on Control now holds them.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The validation surface no longer lives on the WinUI types. The Mode, Kind,
ErrorTemplate, HasErrors and Errors properties are now attached properties
on Uno.Extras.Input.Validation, in Uno.UI.Extras. On WinAppSDK their
handlers are compiled out.

- IInputValidationControl is deleted, along with the per-control DPs and
  the HasValidationErrorsChanged, ValidationError and ErrorChanged events.
  The HasValidationErrorsChangedEventArgs stub is restored.
- InputValidationMode, InputValidationKind and InputValidationError move to
  Uno.Extras.Input and are compile-linked into Uno.UI.Extras.Windows.
- The engine stays on Control. It reads the attached DPs through an
  internal slot that Validation's static constructor fills, and a control
  participates through its validation property alone.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>