Pick dates from a calendar, and give colour fields a real picker

[AllTerrainDeveloper]

Why

Two pieces of feedback:

1. Dates in the builder settings — people didn't know what to type into Earliest date / Latest date (or in what format). They asked for a date picker.
2. Colour field on the front end — <input type="color" class="atf-input"> rendered as a full-width native swatch that read as a broken checkbox. It also couldn't be empty, so an optional colour nobody touched posted #000000.

What changed

Builder: dates are picked, not typed

• New dateInput() in src/ui.ts, used for earliest/latest date, earliest/latest time, default answers on date/time/datetime fields, and the form's Open from / Closes schedule.
• It's the browser's date/time control: it stores the ISO value the server compares (2026-10-31, 09:30, 2026-10-31T09:30) and shows it in the reader's own locale.
• Clicking anywhere on the box opens the calendar (showPicker()).
• The black native icon is swapped for a dashicon so it stays visible on a dark desktop, and the popup's color-scheme follows the box's actual background.
• One-click clear button returns to "no limit".
• A legacy hand-typed value the calendar can't show (e.g. 31/10/2026) is named under the box instead of being silently blanked.
• Datetime fields bound with a date-and-time picker, since a bare date is not a valid min for datetime-local.
• Colour fields get a colorInput() for their default: swatch, hex box, and it can be left empty.

Front end: a colour picker that fits every theme

• The server renders a hex text box with a colour chip. It works with no JS, has a pattern, and is still the one named input.
• src/color-picker.ts turns the chip into a button that opens a panel:
  • saturation/brightness area
  • hue track
  • optional suggested colours (new swatches setting on the Colour field)
  • EyeDropper where the browser supports it
  • No colour on optional fields
• Styled only from the form theme tokens (--atf-surface, --atf-border, --atf-radius-*, focus ring, accent…), with radii capped so pill themes don't distort it. The theme-token contract tests still pass.
• Accessible:
  • aria-expanded/aria-controls on the button and role="dialog" on the panel
  • both tracks are sliders with value text, fully keyboard-operable (arrows, Shift for big steps, Home/End, PageUp/PageDown)
  • Escape closes and returns focus; clicking outside or tabbing away also closes it
• Writes go into the hex box with real input/change events, so logic, validation and submission see one value. It also works in repeater rows added later.
• Values normalise to lower-case six-digit hex on both sides (alltfo_normalize_hex_color() ↔ normalizeHex(), with matching test tables). Inline validation reports a malformed code.

Tests

• tests/phpunit/tests/colorField.php: markup, empty value, default, pattern, swatch cleaning (including an injection attempt), normaliser table, sanitisation. Full PHPUnit run: 793 OK.
• tests/vitest/color-picker.test.ts: colour maths, enhancement, keyboard, swatches, clear, close behaviour, "only one input".
• tests/vitest/date-settings.test.ts: date/time/datetime boxes, clear, legacy-value note, dark detection, colour default control.
• Full vitest: 521 passed. tsc clean, PHPCS unchanged from baseline.

QA (localhost:8889)

• Front end checked on the clean, brutal and neon (dark) themes: the panel picks up each theme's surface, border, radius and button shape.
• Swatch pick, area click, Escape and value posting all verified.
• Builder inspector checked in the dark OpenStation window. Found and fixed one issue: wp-admin's input[type=text] padding outranked the hex box's single-class rule, so the swatch covered the first digit.

🤖 Generated with Claude Code