/*
 * branding.css — the ONE stylesheet an app page includes.
 * ─────────────────────────────────────────────────────────────────────────────
 *
 * Before this, every page hand-listed its own stylesheets and they drifted:
 * `theme.css` documented itself as "loaded by every page" while six pages did not
 * load it, and `login.html` picked up the component kit without the polish layer
 * that is supposed to come with it. Nothing looked broken enough to notice, which
 * is exactly why it stayed wrong.
 *
 * An app page now includes this file and nothing else. The layers, in cascade
 * order:
 *
 *   1. brand-tokens.css  the canonical colour, type, spacing, radius, elevation
 *                        and motion values, light and dark. Everything else reads
 *                        these; no file below may hard-code a colour or a size.
 *   2. theme.css         shared polish that must not know about any page: thin
 *                        theme-aware scrollbars, smooth scrolling, text
 *                        rendering, focus visibility.
 *   3. responsive.css    how every page behaves at every width: the five named
 *                        breakpoints, the container and action-row alias sets,
 *                        overflow hygiene and the touch-target floor. Last,
 *                        because it corrects layout the two layers above set up.
 *
 * The responsive rules were the tail end of theme.css until they grew a contract
 * of their own. They are the one part of the shell that has to outrank a page's
 * inline <style> (a page-local `.btn{min-height:42px}` was quietly beating the
 * shared 44px touch floor), so they are body-scoped where the rest of theme.css
 * is not. Two cascade strategies in one file made it unclear which rule was meant
 * to win, so they are separate files with separate jobs.
 *
 * WHAT IS DELIBERATELY NOT HERE
 *
 * `ui-kit.css` — the component layer — is still injected by brand-runtime.js, and
 * that is not an oversight. It is appended to <head> AFTER the page's own inline
 * <style> so it wins equal-specificity ties and can genuinely restyle a page.
 * Pulling it in here would load it BEFORE those inline styles, handing the tie
 * back to each page, which would silently change the look of all 17 app pages.
 * The injection also honours `window.__BRAND_NO_UIKIT__`, which the four bespoke
 * marketing pages set on purpose to keep their own layouts.
 *
 * Page-specific stylesheets (settings-ui.css, icon-rail.css,
 * outline-workspace.css) load AFTER this file, which is correct: they are meant
 * to build on the shell, not to be overridden by it.
 *
 * The split is enforced by backend/tests/test_branding_css_is_the_one_include.py
 * so it cannot rot again: app pages must include this and must not re-list its
 * layers; marketing pages take brand-tokens.css alone.
 *
 * @import is used rather than concatenating the files because each layer stays
 * separately editable and separately meaningful. This is a local-first app served
 * from disk or from one container, so the extra requests cost nothing that a
 * human can perceive.
 */

@import url("brand-tokens.css");
@import url("theme.css");
@import url("responsive.css");
