/**
 * Carrier branding overlay — the SHARED BASE.
 *
 * ── THE BRAND BLOCKS ARE NOT IN THIS FILE ANY MORE (ND-766, 2026-08-14) ─────
 *
 * Each brand's four `:root[data-brand='k']` blocks now live in that brand's own
 * folder:
 *
 *   ui/brands/<key>/brand.json    label, swatch, and `"default": true` for one
 *   ui/brands/<key>/tokens.css    the four blocks — dark, light, header pair x2
 *   ui/brands/<key>/site.css      optional, per-brand marketing-site overrides
 *   ui/brands/<key>/pages/*.html  optional, overrides ui/site/<same-name>.html
 *
 * The backend DISCOVERS those directories (discoverBrands in ai-hub-v3
 * handlers/v3/site-template.js) and serves this file followed by every brand's
 * tokens.css as ONE stylesheet, at the URL this file was always served from. So
 * adding a carrier is `cp -R ui/brands/trident ui/brands/newco`, edit brand.json,
 * and nothing else — no allowlist, no switcher button, no swatch rule, no
 * <ui-option>, no backend deploy. There is no ui/branding/brands.json any more;
 * the filesystem is the registry, exactly as it is for plugins.
 *
 * WHAT IS STILL HERE: the @font-face declarations, because they are shared
 * infrastructure rather than one brand's property — Manrope is referenced only by
 * trident and IBM 3270 only by greenscreen, so each is still downloaded only by
 * the brand that names it (the download is triggered by --font matching, not by
 * the declaration existing). Keeping them here also keeps their URLs and the
 * font files themselves in one directory. A NEW brand wanting its own face may
 * declare @font-face in its own tokens.css; the concatenated output is one
 * stylesheet, so it works identically.
 *
 * Also still here: the cascade and specificity rules below, which every brand
 * folder depends on and none should restate.
 *
 * It is loaded after sdk.css (ai-hub-v3 handlers/v3/shell-template.js:62 — the
 * branding <link> is always emitted LAST), so a token redeclared here or in any
 * brand file wins on source order and sdk.css is never edited.
 *
 * The four brands that exist today, each keyed on a `data-brand` attribute set on
 * <html> by the server. The server-side plumbing is NOT in this file.
 *
 *   trident       OneShield's own identity — acid lime on near-black. DEFAULT.
 *   nukor         the stock SDK indigo the logged-in app already wears —
 *                 reproduced, with its two known contrast failures corrected.
 *   meridian      conservative institutional carrier — navy + gold
 *   greenscreen   CRT green phosphor terminal, monospace throughout
 *
 * REMOVED 2026-08-14: 'amber' (CRT amber phosphor), 'ose' (OneShield Enterprise)
 * and 'oms' (OneShield Market Solutions). Recover them from git history if a demo
 * wants them back — under this design that means restoring one directory.
 *
 * ══════════════════════════════════════════════════════════════════════
 * UNBRANDED STILL WORKS — deliberately
 * ══════════════════════════════════════════════════════════════════════
 *
 * Every rule below is gated on an attribute selector. With no `data-brand` on
 * <html>, NONE of these blocks match and the stock SDK appearance returns
 * untouched — this file then costs one HTTP request and changes nothing.
 *
 * The server currently defaults a cookie-less visitor to 'trident', so there is
 * no unbranded state in normal operation. Keep the property anyway: it is what
 * makes "is this bug mine or the SDK's?" answerable in one step (remove the
 * attribute in devtools), and it is the only reason this file can ship to a
 * deployment that has not opted into branding at all.
 *
 * ══════════════════════════════════════════════════════════════════════
 * READ THIS FIRST: every colour must be set TWICE (and why)
 * ══════════════════════════════════════════════════════════════════════
 *
 * Specificity is (a,b,c) = (#id, .class/[attr]/:pseudo-class, type/::pseudo-elt).
 * The trap is that ATTRIBUTE selectors score in the SAME column as classes —
 * the b column — not the type column. `:root` is a pseudo-class, not an element,
 * so the c column is 0 for every selector involved here:
 *
 *   sdk.css   :root                                (0,1,0)
 *   sdk.css   :root[theme='light']                 (0,2,0)   <- sdk.css:292
 *   ours      :root[data-brand='x']                (0,2,0)   <- TIES sdk's light
 *   ours      :root[data-brand='x'][theme='light'] (0,3,0)   <- beats it outright
 *
 * Consequence, and it is the OPPOSITE of the single-brand warning this file
 * used to carry: our dark block TIES sdk.css's light block at (0,2,0), and a
 * tie is broken by source order, which we win because we load last. So a colour
 * set only in `[data-brand='x']` does not get discarded in light mode — it
 * LEAKS INTO light mode and overrides sdk's carefully lightened value. A brand
 * that sets only its dark colours renders a dark-on-dark palette against light
 * mode's white page.
 *
 * Either way the instruction is identical, so it is stated once and absolutely:
 * EVERY COLOUR IS SET IN BOTH BLOCKS. The two blocks below each brand carry the
 * same set of keys, deliberately, so a missing one is visible as an asymmetry.
 *
 * Three tokens behave differently and are handled accordingly:
 *
 *   --accent-hover   NOT set here, on purpose. sdk.css defines it in both of its
 *                    own blocks as a color-mix over var(--accent) — toward white
 *                    in dark, toward black in light. Leaving it alone means it
 *                    re-derives correctly from each brand's accent in each theme
 *                    for free. Setting it would break that and gain nothing.
 *   --chart-*        sdk.css defines these ONLY in its `:root` (0,1,0). Our
 *                    (0,2,0) beats that in BOTH themes, so a chart colour set in
 *                    a dark block applies in light mode too. Where a brand needs
 *                    different chart values on a white page it must still say so
 *                    in its light block — same rule, different reason.
 *   --font / --mono  sdk.css's light block does not touch them, and nothing else
 *                    outranks (0,2,0). Set ONCE, in each brand's dark block.
 *
 * Verified against sdk.css as it stands: `:root[theme='light']` is at line 292
 * (the older comment in this file said 234-257, which is now the elevation
 * scale — the file has grown). It is the ONLY selector in sdk.css that
 * redefines the palette per theme; the header comment there mentioning
 * `ui-app[theme]` / `ui-platform[theme]` scoping is stale, no such blocks exist.
 *
 * ══════════════════════════════════════════════════════════════════════
 * Scope
 * ══════════════════════════════════════════════════════════════════════
 *
 * Colour, typeface and the carrier logo. Spacing, radius, elevation, z-index
 * and the type scale are deliberately absent: they affect layout and component
 * internals in ways a colour swap does not, and there is no visual-regression
 * tooling yet (ND-46/47) to catch a mistake. Do not add them here without
 * sign-off from whoever owns the SDK design tokens. None were added for this
 * change, including for the two monospace brands.
 *
 * After editing, run from ai-hub-workspace/plugins/com-oneshield-sdk-ui:
 *   npm run verify:css     (proves the browser did not silently drop a rule)
 *   npm run lint:sdk
 * then view it in a real browser in BOTH themes. NEITHER GATE READS THIS FILE —
 * verify-css parses sdk.css only and lint:sdk does not look at the branding
 * overlay — so they prove the SDK is unbroken and prove nothing about anything
 * below this line. No gate can prove a colour change kept its contrast.
 */

/* ══════════════════════════════════════════════════════════════════════
   WEBFONT — Manrope, self-hosted (used by `trident`)
   ══════════════════════════════════════════════════════════════════════
   Self-hosted rather than an @import from Google Fonts, which also sidesteps
   the ordering trap the @import route carries: an @import that is not the very
   first rule in the file is dropped silently, and this file now opens with a
   large comment block that makes "first rule" easy to get wrong.

   One variable file, latin subset, axis wght 200..800 — covers the 400/500/700
   body weights and the 800 headings the brand uses, in 24 KB. Downloaded from
   the URL Google's own css2 endpoint serves for this face (Manrope v20).

   Latin subset only (U+0000-00FF plus punctuation). Names carrying characters
   outside Latin-1 — Polish, Czech, Turkish insureds — will fall through to the
   next family in the stack for those glyphs. Add the latin-ext file if that
   turns out to matter.

   Referenced by --font under [data-brand='trident'] only, so the other three
   brands never trigger the download. Manrope is OneShield's CORPORATE typeface
   (oneshield.com self-hosts five weights of it and declares
   `font-family: Manrope, Arial, sans-serif`), which is why the trident brand
   takes it. The `ose` and `oms` brands also used it; both were removed
   2026-08-14, and this face is kept because trident — the DEFAULT brand — needs
   it. */
@font-face {
  font-family: 'Manrope';
  src: url('/plugin-assets/com-oneshield-nukor-platform/branding/Manrope-Variable.woff2')
    format('woff2');
  font-weight: 200 800;
  font-style: normal;
  font-display: swap;
}

/* ══════════════════════════════════════════════════════════════════════
   WEBFONT — IBM 3270, self-hosted (used by `greenscreen`)
   ══════════════════════════════════════════════════════════════════════
   THIS FONT IS THE POINT OF THAT BRAND AND IT WAS PREVIOUSLY MISSING.

   The terminal brands used to name 'IBM Plex Mono' at the head of their
   stack. Nothing ships that family, so the name matched nothing and the stack
   fell through to JetBrains Mono / SFMono / Menlo — all modern, humanist,
   carefully hinted screen faces. They are the OPPOSITE of clunky, which is
   exactly why the brands did not read as period-correct however dark the
   background got. A font-family that names an absent family fails silently:
   there is no console warning, the text just renders in something else.

   3270-Regular.woff is a webfont build of IBM's own 3270 font — the character
   set of the IBM 3270 display terminal, redrawn from the original bitmaps.
   It is the actual typeface of the mainframe era rather than an evocation of
   one: fixed pitch, blocky, flat terminals, the slashed zero and the squared
   lowercase that the fallbacks all round off. 106 KB, CFF outlines, name
   table reports family 'IBM 3270' (read out of the file, not assumed — the
   family name is what --font must match, and getting it wrong is the same
   silent failure as above).

   Licence: 3270-LICENSE.txt beside this file.

   ONE WEIGHT ONLY, and that is deliberate. A 3270 terminal had no bold — it
   had brighter. Declaring `font-weight: 400` alone lets the browser
   synthesise bold by smearing the glyph, which is very close to what a
   double-strike actually looked like. Declaring `100 900` would have made the
   SDK's headings and <strong> render identically to body text and flatten the
   hierarchy the components rely on.

   font-display is `block`, NOT `swap`, and this is the one place in this file
   where that is right: this brand sets --font to a monospace, so a swap
   would repaint the entire product from a proportional fallback to a fixed
   pitch mid-load and reflow every table in it. A brief invisible flash is the
   better failure. Only referenced by greenscreen, so the other three brands
   never trigger the download. (`amber`, the other terminal brand, was removed
   2026-08-14; this face stays for greenscreen.) */
@font-face {
  font-family: 'IBM 3270';
  src: url('/plugin-assets/com-oneshield-nukor-platform/branding/3270-Regular.woff')
    format('woff');
  font-weight: 400;
  font-style: normal;
  font-display: block;
}

/* ══════════════════════════════════════════════════════════════════════
   A NOTE ON THE LOGO, WHICH IS SHARED BY ALL FOUR BRANDS
   ══════════════════════════════════════════════════════════════════════
   The trident mark is an inline data: URI rather than a .svg file on disk, and
   that is a deliberate choice for a brand SWITCHER specifically.

   An SVG loaded through background-image is an independent document: it cannot
   see currentColor, the page's CSS variables, or the @font-face above. Its
   colours are baked in at author time.    With seven brands x two themes that is
   fourteen separate files that must be kept in geometric lockstep, and the mark
   would silently stay lime while the rest of the product turned navy. Inlining
   it means the fill is a literal in each block, so the mark repaints with the
   brand — which is the entire point of the demo.

   Encoding rules that make this work, all of which fail SILENTLY if broken:
     - '#' MUST be %23. Unencoded it terminates the URI as a fragment and the
       background simply does not render — no console error.
     - Quotes inside the SVG are %27 so they cannot collide with the quotes
       wrapping the url().
     - Spaces are %20; the path data uses commas as separators so it contains
       none at all.
   Verified rendering in headless Chrome at 22px on all eight brand/theme
   backgrounds before being committed here.

   The viewBox is 0 0 32 32 — square — so --brand-logo-width and
   --brand-logo-height are BOTH 22px. background-size: contain fits the image
   inside that box and letterboxes any mismatch, so a non-square value here
   would render the mark smaller rather than stretched.

   The mark is three prongs on a shaft: the carrier writes exactly three product
   lines (personal auto, workers' compensation, and the TriPak commercial
   package), so the count is not decorative.

   --brand-wordmark-display is deliberately LEFT AT ITS DEFAULT (`block`) — see
   the note in the trident block for why setting it to `none` would be a bug
   here rather than a tidy-up. */

/* ══════════════════════════════════════════════════════════════════════
   ══════════════════════════════════════════════════════════════════════
   THE GLOBAL HEADER — --header-bg per brand
   ══════════════════════════════════════════════════════════════════════
   ══════════════════════════════════════════════════════════════════════

   sdk.css leaves the header on --surface in every brand, so the one piece of
   chrome that is visible on every screen is the only piece that is not
   branded. These blocks set it deliberately.

   TWO THINGS HERE ARE NOT WHAT THEY LOOK LIKE. Both were checked against
   sdk.css rather than assumed, and both fail SILENTLY when got wrong.

   ── (1) --header-text AND --header-accent ARE INERT. DO NOT TRUST THEM. ──

   sdk.css:393-394 DEFINES both, on ui-platform. Nothing anywhere READS
   either one. Searching the SDK, this plugin and the v3 backend for the two
   names returns exactly three things: those definitions, the lint allow-list
   at tools/lint-sdk.mjs:71-72, and nothing else. The only header token with a
   live consumer is --header-bg, at sdk.css:421.

   So the header's text colour is NOT --header-text. It is ordinary inherited
   --text, arriving from :root by way of ui-platform. Which means:

       --header-bg MUST CONTRAST WITH --text, NOT WITH --header-text.

   That is not pedantry, it removes an option. The obvious move for meridian
   is a deep navy header bar in LIGHT mode — very much that carrier's look.
   It cannot be done: light-mode --text IS the navy (#0a1826), so the bar
   would render navy on navy, and adding --header-text: #ffffff beside it
   would read in review as a fix while having no effect whatsoever. Every
   value below is therefore chosen against its own brand/theme --text, and
   the two light "ink on dark bar" brands are deliberately not attempted.

   --header-text IS still set below, to precisely the --text each block
   already resolves to. That is documentation rather than effect: it costs
   nothing today, it states the coupling at the point someone will read it,
   and if the token is ever wired up the header keeps rendering exactly what
   it renders now instead of lurching. --header-accent is left alone — there
   is no correct value to state for something with no consumer and no
   fallback site. If either is ever given a consumer, revisit this whole
   section; the light-mode navy bar becomes possible the moment it is.

   ── (2) THE SELECTOR MUST REACH ui-platform, NOT :root ──

   sdk.css declares --header-bg on the `ui-platform` ELEMENT (line 391), not
   on :root. A custom property declared ON an element always beats one
   INHERITED into it, whatever the specificity of the rule it was inherited
   from — they match different elements, so specificity never gets compared.
   Therefore:

       :root[data-brand='x'] { --header-bg: ... }      <-- INERT. Silently.

   loses to ui-platform's own `--header-bg: var(--surface)` for the entire
   subtree, and the header simply stays on --surface with nothing reported.
   This is the trap that makes header branding look done when it is not.

   Each brand below carries BOTH selectors:
     :root[data-brand='x']               — for any ui-global-header mounted
                                           outside a ui-platform, which falls
                                           back to var(--surface) at
                                           sdk.css:421 and so reads :root
     :root[data-brand='x'] ui-platform   — (0,2,1) against sdk's (0,0,1), for
                                           the real header in shell.html
   and the light pair repeats it at (0,3,1).

   --header-border is deliberately NOT set: it already resolves through
   ui-platform to each brand's own --border, which is the right answer in all
   four. --header-height is layout, and out of scope for this file. */