Self-hosted: accent needs a colour control and inline validation, not a bare text field

[feruzm]

Follow-up to #1358, which made configuration.general.styles.accent reachable but as a plain string input. That was deliberate and is not sufficient.

The gap

Type banana into the accent field and save. The save succeeds, the value is stored, and the site silently keeps the style template's own colour. Nothing tells the owner their input was not a colour, and nothing on the page changes, so the natural reading is that the feature is broken.

array fields already show inline validation (config-editor.tsx renders a per-field error under the control). string fields have no such surface at all, so this is not a matter of adding a message to an existing mechanism.

Why it was deferred

The editor renders string, select, boolean, number and array. There is no colour type, so a picker needs a renderer case of its own. And a bare <input type="color"> cannot express "unset", which is the value every live instance currently holds and the state an owner has to be able to return to. That is the same constraint that gave the font preset its explicit '' "Theme default" option.

What this needs

1. A color field type with a renderer case: a picker paired with a hex text input, since the two have to stay in sync and the text input is what expresses empty.
2. Inline validation on string fields generally, so an accepted-but-meaningless value is visible at the point of entry rather than by its absence of effect.
3. A way to clear back to the template default that is obvious, matching the font preset's "Theme default" entry.

Worth pairing with a live preview: theme-appearance.ts already derives the hover fill, the on-accent text and the corrected readable text purely, so the values can be shown without saving.

Not in scope

The engine itself. theme-appearance.ts already ignores an unparseable accent and falls back, which is why this is a feedback problem rather than a correctness one.

[feruzm]

Done across two PRs.

#1364 gave the accent its own control: a native swatch beside a text input, a Clear button back to the template default, and an inline message. Validation calls parseHexColor, the function the appearance engine itself uses, so the panel cannot accept a value the site drops. A plausible hand-rolled /^#[0-9a-f]{3,8}$/ would have accepted #0969daff, which the engine refuses because alpha on a fill is a readability hole no contrast correction closes.

#1367 built the generic half: a validate hook on string fields, wired for the two whose resolver genuinely refuses something. The learn-more link (the value becomes an href, so a javascript: one must never reach the DOM) and the create-post URL (a refused address silently falls back to the built-in editor).

Scope stayed narrow on purpose. Only fields whose resolver already refuses a value carry a validator, since inventing a rule the app does not enforce would reject input the site would have accepted.

Both are live: deployed in sha-1dda476, and the messages are confirmed present in the served bundle.

The community-mode gap found while reviewing #1367 is tracked separately in #1368.