Error display for Select, DatePicker, Checkbox, RadioGroup

[shanerbaner82]

Summary

The validation audit (core mobile-air#301 context) found is_error/supporting rendered ONLY on text inputs — every other form element silently swallowed validation errors on all targets. This adds the display to the four commonly-validated elements on every layer:

• iOS (SwiftUI): destructive border/tint on error, supporting Text below the control, error message announced via the a11y hint channel unless an explicit hint is set — same conventions as the shipping text inputs.
• Android (Compose): first-class isError/supportingText on the OutlinedTextField-based controls (Select, DatePicker trigger), destructive checkbox tint + supporting Text, RadioGroup label tint + supporting Text; hint-channel announcement likewise.
• PHP elements: supporting and error/isError/is-error attributes + supporting()/error() builder methods mirroring BaseTextInput.

Deliberately NOT added: Slider, Toggle, Chip, ButtonGroup — rarely validated; the same pattern applies when needed.

Blessed usage (explicit-only display, per the core validation semantics):

<native:select native:model="color" :options="$colors"
    :error="$errors->has('color')"
    :supporting="$errors->first('color')" />

Verification

• Web emitters (mobile-web#1 counterpart): 6-check render harness + an 18-check end-to-end settings-screen harness in xclone, all green.
• Android: compile-verified in a real app build (:app:compileDebugKotlin clean with these renderers compiled in) and exercised on-device via xclone's /settings demo screen.
• iOS: the Swift is a pattern-copy of the shipping text-input renderers but has NOT been through an Xcode build yet — please build once before merging.

🤖 Generated with Claude Code