/* ══════════════════════════════════════════════════════════════════════════ animalsss — one palette, two themes, five colours to choose from. The site had grown four unrelated colour schemes: an amber-on-navy marketplace, a light-grey blog, seventy-six farm-manager screens that were dark by default and seventy that were light, and a community feed on its own warm greys. Nothing agreed, and "dark mode" was a navbar that turned navy while the page under it stayed white — because :root in marketplace.css held *light* values and the class named theme-light repainted the components, which is backwards. So this file is the only place a colour is given a *meaning*. Everything else in the codebase either already used a token or was rewritten to (see scripts/recolor_css.py), and every legacy token name — --amber, --bg-card, --cf-line, --mph-primary, --pf-page, --detail-surface, all 199 of them — is re-pointed here. ── Where the colours come from ── This file holds no hex of its own. The paint lives in palette.css, which is @generated by scripts/make_palette.py: five palettes (plum, orchid, berry, clay, ink), and each one emits a full light set (--l-*) and a full dark set (--d-*) whose every ratio the script *measures* before it will write the file. This file turns those into the named roles the components read — --primary is var(--l-primary) in light and var(--d-primary) in dark, and so on down — and adds nothing but the shapes, the shadows and the motion, which carry no hue. Pick the palette with `data-accent` on (palette.css explains that end). The light block and the dark block below draw from the *same* palette, so one choice re-tints both themes at once — there is no second place to keep in step, which is the whole point of the split. ── Why html:root and not :root ── Eighty-seven farm templates open their own