/* ══════════════════════════════════════════════════════════════════════════
   sf-final-typography.css — ONE TYPE SYSTEM, EVERY PAGE.

   THE STANDARD is the client's own shipped pair, declared in the built
   theme.css and served from brand_assets/fonts/ (self-hosted, no CDN):

       --sf-font-display   Sora      (variable 100–800)   headings, brand marks
       --sf-font-body      Manrope   (variable 200–800)   everything else
       --sf-font-mono      JetBrains Mono (variable 100–800)  lot codes, refs

   WHAT THIS SHEET IS FOR. The inventory (26 built pages, computed styles read
   in a real browser) found SIX distinct font stacks on the site and four of
   them were nobody's decision:

     1. tailwind's preflight sets `html { font-family: ui-sans-serif … }` and
        tailwind.min.css loads AFTER theme.css / sf-base.css / sf-refresh.css,
        so the SYSTEM sans was the inherited default on every tailwind page.
        404.html has no body-level font rule at all, so the WHOLE PAGE — nav,
        headline, body copy, buttons — rendered in the system sans.
     2. invoice.html, verify-email.html and unsubscribe.html link no tailwind,
        so their root fell all the way to the UA default: TIMES NEW ROMAN.
     3. admin.html links fonts.css + admin.css and NOTHING ELSE, so its
        `body { font-family: var(--sf-font-body, 'Public Sans' …) }` never saw
        the variable and 820 elements rendered in PUBLIC SANS — a face this
        client does not use.
     4. coa-library.html / login.html / register.html each carry a page-local
        `h1,h2,h3,h4,h5,h6 { font-family: var(--sf-font-body) }`, so their
        headings were set in the BODY face while every other page's headings
        were set in the display face. invoice.html and gate.html had the
        mirror-image defect — `body { font-family: var(--sf-font-display) }`,
        i.e. body copy in the DISPLAY face.

   WHY THIS SHEET CAN WIN. index.mjs links it LAST in <head>, after theme.css,
   sf-base.css, sf-refresh.css AND tailwind.min.css. Every rule below is a BARE
   ELEMENT selector (0,0,1) or a single class (0,1,0) on purpose: it beats the
   earlier sheets on equal specificity by document order, and it deliberately
   LOSES to anything more specific. That is the whole trick behind the heading
   line-heights — `h1 { line-height }` fixes the fourteen pages whose h1 was
   inheriting body leading at 1.72, and does not touch `.sf-hero-title` or
   `.pg-h1`, which set their own at 1.04.

   THE TOKEN BLOCK IS GENERATED. 01-typography.mjs rewrites it in the copy that
   ships, reading the real values out of the built theme.css, so the pair here
   can never drift from the pair the build solved — and so admin.html, which
   links no theme.css, still resolves it. The values below are the fallback if
   the module never runs.
   ══════════════════════════════════════════════════════════════════════════ */

/* SF:FONT_TOKENS_START */
:root {
  --sf-font-display: 'Familjen Grotesk', 'Familjen Grotesk Fallback', 'Segoe UI', system-ui, sans-serif;
  --sf-font-body: 'Inter', 'Inter Fallback', 'Segoe UI', system-ui, sans-serif;
  --sf-font-mono: 'JetBrains Mono', 'JetBrains Mono Fallback', ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
}
/* SF:FONT_TOKENS_END */

/* ── 1. The inherited default is the brand body face, on every page ──────────
   `html` is the one that matters: it is what tailwind's preflight claims and
   what the UA default (Times) falls back to. Setting body too means a page
   that scopes something to `body` still starts from the same place. */
html {
  font-family: var(--sf-font-body);
}
body {
  font-family: var(--sf-font-body);
  /* invoice.html links no sf-base.css, so its body carried NO line-height at
     all and every paragraph on it computed `normal`. */
  line-height: var(--sf-body-lh, 1.6);
}

/* ── 2. Headings are the display face, with heading leading ─────────────────
   Bare element selectors: they override the three pages that named the body
   face for headings, and they lose to every class-level rule that has already
   solved a heading's size and leading deliberately. */
h1, h2, h3, h4, h5, h6 {
  font-family: var(--sf-font-display);
}
h1 { line-height: 1.12; }
h2 { line-height: 1.2; }
h3 { line-height: 1.28; }
h4, h5, h6 { line-height: 1.35; }

/* ── 3. Form controls inherit ───────────────────────────────────────────────
   tailwind's preflight already does this; the four pages that do not link
   tailwind did not, which is why invoice.html's checkboxes computed ARIAL. */
button, input, select, textarea, optgroup, option {
  font-family: inherit;
}
/* Same three pages, same reason: the UA's `font:` shorthand on a <button> also
   resets its leading, so five CTAs computed `line-height: normal` while every
   button on a tailwind page inherited the body's. */
button {
  line-height: inherit;
}

/* ── 4. One mono, and it is a shipped face ──────────────────────────────────
   Was three: 'Courier New' on the COA filename chips, bare `monospace` on the
   checkout bank details and the tracking number, and `ui-monospace, SFMono-
   Regular, …` in the admin studio — i.e. a different typeface per operating
   system, three times over. JetBrains Mono is already in brand_assets/fonts/
   and adds no network request off this origin. */
code, pre, kbd, samp, tt {
  font-family: var(--sf-font-mono);
}
.filename-chip,      /* coa-library — COA file names */
.studio-mono {       /* admin — the studio's numeric readouts */
  font-family: var(--sf-font-mono);
}

/* ── 5. The small-print floor: nothing renders under 11px ───────────────────
   NOT a re-scale — the micro-label register (badges, pills, eyebrows) is a real
   device on this template and it stays. These are only the rules that had
   fallen under 11px, where the letterforms stop resolving; everything at or
   above it is left exactly as designed. The measured floor was 8.8px.

   These five are the ones a stylesheet can reach. The other 23 are inline
   `style="font-size:…"` — several of them written by admin.js at runtime — and
   01-typography.mjs lifts those by string edit; see the FLOOR table there. Note
   that .tile-size-pill is the one written in px rather than rem, so the module's
   rem table cannot see it and this rule is its only route.

   A REM FLOOR IS NOT A FLOOR — it moves with the root, and this root MOVES.
   sf-refresh.css roots the storefront at clamp(17px, 0.35vw + 15.7px, 18px),
   so 11px is 0.611rem at the CEILING and 0.647rem at the FLOOR. 0.64rem was
   solved against 18 and therefore clears 11px only while the root is above
   17.1875px — i.e. only at viewport widths >= 425px. MEASURED below that:
   .std-cat, .std-num and .pg-seal span all render 10.89px at 375px wide, the
   commonest phone width there is, on the one page the nav calls Research.
   So the floor is stated in PIXELS and the rem rides above it. max() rather
   than clamp(): 0.64rem tops out at 11.52px, so an upper bound would be
   decoration. The same reasoning is why .tile-size-pill was already in px. */
.pg-chip-k { font-size: max(11px, 0.64rem); }   /* was 0.56rem → 10.1px */
.pg-seal span { font-size: max(11px, 0.64rem); }/* was 0.55rem →  9.9px */
.std-cat { font-size: max(11px, 0.64rem); }     /* was 0.58rem → 10.4px (.std-num inherits) */
.tile-size-pill { font-size: 11.5px; }          /* was 11px hard-coded */
.nav-group { font-size: max(11px, 0.69rem); }   /* admin sidebar group labels, was 9.6px */
