[FormField]: single clearable prop shared by DateField and TimeField

[ly-tempel-bitweb]

Problem

clearable exists twice for the same visible affordance. tedi-form-field has
one (default false) that renders .tedi-form-field__clear, and
tedi-time-field has its own (default true) that renders
.tedi-time-field__clear in its action row. A consumer wrapping a time field in
<tedi-form-field clearable> gets two clear buttons in the same box, and
there is no single place to turn the affordance on or off.

The cause is that DI only flows control → field: TEDI_FORM_FIELD_CONTROL lets
the field find its control, but a control can never read anything from its field.
size has the same symptom — tedi-date-field declared its own size input
that was never read (no template binding, no host class, no
tedi-date-field--* rule exists), while the real sizing came from the wrapper.

Solution

• Add TEDI_FORM_FIELD (FormFieldContext), the mirror of
  TEDI_FORM_FIELD_CONTROL, provided by tedi-form-field. Field-level settings
  are declared once and read by the control.
• Declare clearable only on tedi-form-field. Date and time fields drop their
  own input and resolve formField?.clearable() ?? false.
• Add optional ownsClearButton to FormFieldControl. Date and time set it, so
  the field skips its generic clear button — their button cannot move into
  form-field, because the picker button beside it is the overlay's anchor and the
  design puts clear before it in the action row.
• Remove the dead size input from tedi-date-field.
• Storybook: group size and clearable under Form Field inputs for both
  fields, matching TextField, so wrapper-owned args read separately from the
  control's own.

DoD

• The component is developed using best practices, conventions, and modern frontend trends
• The component follows BEM naming conventions (if applicable)
• The component implementation matches the Figma design, including all defined states and interactions
• The component supports responsiveness and scales across breakpoints (if applicable)
• The component does not introduce runtime errors or warnings
• Linter passes
• Component has export if needed
• The component has unit tests with at least 80% code coverage
• CodeCov passes minimum coverage threshold
• The component has passed code review
• The component has passed Chromatic visual review
• Storybook stories are created:
  • Cover all Figma variations
  • Include edge cases, empty/error states
• Component’s API (props, slots, events) is documented
• ZeroHeight is updated with design/development guidelines
• External dependencies used in the component are documented in Confluence with rationale.
• Semantic commit format is used (for semantic-release)
• External libraries comply with validated open source licenses
• Component is versioned correctly and ready for release if required
• Update statuses page in Zeroheight