Dark mode on core colour tokens, plus backend and bundled-plugin dark-mode fixes

[LukeTowers]

Rebuilds dark mode on core's new colour tokens (wintercms/winter#1541) and fixes the dark-mode problems that turned up across the backend and the bundled plugins while doing it.

Requires Winter 1.2.15 (the release carrying #1541) and therefore PHP 8.1. composer.json now declares both.

Dark mode on core's colour tokens

Core now paints through --wn-* tokens, so dark mode redefines those instead of overriding each rule that uses them. The .dark block maps the neutral tokens onto the existing --drk-* palette by role: text, surfaces, borders, inputs, hover and selection. It also covers the few identity tokens darkmode.css already repainted consistently.

That made 86 declarations redundant, and they are removed along with 48 rules left empty. Each removal was measured, not eyeballed:

• On 25 backend pages in dark mode, every element's and pseudo-element's colours, border colours/widths/styles, outlines, shadows, fill/stroke and opacity were captured.
• The token block was then applied, and a declaration was removed only if doing so changed nothing on any page where it matched.
• Declarations that matched nothing on those pages are kept, since their redundancy couldn't be shown.

The token block also darkens about 650 element-properties darkmode.css never covered, which were rendering their light-mode colours in dark mode. That includes dark slate text and icons on dark surfaces (pagination, record navigation, file-upload names, the component list), light borders and placeholders, and the recordfinder, datepicker and sweet-alert panels.

Dark-mode fixes

Tabs

• Primary tabs (e.g. Settings/Meta in the CMS and Pages editors) were inverted: the inactive tab was darker than the active one, and neither joined the panel below. The active tab now takes the canvas colour of the panel it opens, as in light mode. Inactive master-area tabs get the same winged shape in a recessed accent, instead of a flat box stamped onto the teal bar.
• Secondary tabs glowed bright brand teal, with the active tab white behind light text (about 1.5:1). Content tabs (Content/Sidebar/Preview) had white edges, white inactive wings and a white line under them. Both now sit on the accent scale and join what's below.

Widgets

• Date picker: today was navy on a dark cell, and the selected date white on brand green (about 2:1).
• Time picker: the selected hour sat in a pale bubble behind light numerals.
• Icon picker: the modal kept its light panels behind dark-mode text. Its scoped styles also beat the first override, which left it half light and half dark.
• Input-group addons stayed a light #eee box.

Layout

• Selected rows in the tree, file list and asset list were a grey block, because core paints them with a text token. They now use the selection colour.
• Nested forms in a fancy layout took the header's accent colour. The header rule is now scoped to the top-level form, the way core scopes it.
• The fancy breadcrumb now sits entirely on the accent scale. Before, the non-current segments, arrow tips and separators kept the runtime brand teal.
• Logos: the side-menu logo pointed at a file #1541 removed. The dashboard and empty-editor logos had dark lettering on dark surfaces.
• The icon-only delete button in the CMS and Pages toolbars no longer adds an empty label's margin.
• The earlier audit fixes (G-series) are also in this PR: btn-default, fieldsets, control-table cells, list totals, editor toolbars, media previews, the event log, the theme picker, filters, relation embeds and CMS/Builder tab wings.

One dark palette

Following darkmode-audit/color-misuse-audit.md, the one-off colours now resolve to roles. Before, there were eight different colours for "active", a traffic-light rainbow on media titles, four colours on one sort control, salmon/coral/gold/yellow headings, neon named colours on the user statistics widget and five unrelated link blues.

• --drk-color-accent is used for links, active indicators and focus rings. It is the brand secondary lifted toward white, derived with color-mix() like the fancy accent, so custom branding follows.
• --drk-bg-color-selection is used for every selected or active background.
• --drk-color-success and --drk-color-warning sit beside --drk-color-danger.
• Headings use the text colour, and descriptions and empty states use the muted colour.

The fancy accent (header, tab bars, breadcrumb) still derives from the live --brand-secondary, which core now emits.

Audit docs and tooling

The audit that drove this work (reports, handoffs, design prototypes, the colour-token tooling used for #1541 and the dark-tokens harness that measured the dark-mode removals) is not part of this PR. It lives on the standalone wip/darkmode-audit branch.

Verification

• Light mode is unchanged: the same 25 pages capture identically before and after.
• Dark mode: every difference against the previous build is one the token block was predicted to make and was reviewed. The interactive states were each checked in the real build rather than with injected CSS: the date/time/icon pickers, tab switching, tree selection and the modals (list setup, record finder, relation "add", delete confirmation).
• A screen recording switches every main screen from light to dark with the skin's own appearance menu and runs the interactive states above. The run finished with no console errors and no new system.log errors.

Known limits

• The dark logo swap uses a root-absolute /modules/... URL, because Vite would otherwise try to resolve a relative path into core. On a subdirectory install those logos are simply absent.
• 178 dark-mode declarations remain. They express deliberate element-specific choices rather than duplicating a token.
• Several fixes here still override selectors (some with !important) rather than redefining a variable, because the colours they target never became tokens in core: the brand-derived fancy chrome, named-colour literals, the list/tree row states, the date/time pickers, the switch knob, the icon picker and the logos. Tokenise the remaining backend colours so dark mode can be a pure variable redefinition winter#1552 tracks tokenising them, after which those overrides can be deleted.
• The Winter.Translate language badge is still cream-coloured on dark fields. Its fix belongs in that plugin.

Summary by CodeRabbit

• Style
  • Improved dark-mode contrast and consistency across buttons, button groups, dropdowns, tabs, toolbars, tables, forms, previews, and media controls.
  • Refined navigation, borders, backgrounds, text colors, hover states, and accent colors for a more consistent dark appearance.
  • Updated fallback logos on authentication screens and in the side menu.