/*
  gb-footer-legal.css — the footer legal row, made thumb-sized. One rule, nineteen pages.

  WHY THIS FILE EXISTS AT ALL, because "one commit, footers only" could also have meant nineteen copies of
  the same three declarations. Every public page carries the same legal row — About · Partners · Privacy ·
  Terms · Refund · Data Retention · Acceptable Use · support@ — as a bare inline-styled <div> with `·` spans
  and NO class on the anchors, and `grep -rln "Data Retention" public/_lib/ public/assets/` returns nothing,
  so there is no shared partial to fix. Pasting the rule into thirteen stylesheets and three inline <style>
  blocks would have created sixteen places one decision has to be changed. The house rule is the opposite:
  if the same logic would exist in two files, it belongs in one. So: one file, linked from the pages that
  need it. Chief's own lane rule from tonight applies to it — "a file's lane is decided by who LOADS it, not
  which folder it sits in" — and every loader is a public marketing/legal page.

  WHAT IT DOES, and what it deliberately does NOT do.
  The type does NOT grow. These are legal links under a copyright line; enlarging them would shout them over
  the page's own hierarchy. Only the TAP BOX grows, to the 44px minimum, exactly as `.gb-foot-links a`
  already does on home.html (gb-marketing.css:285). That rule shipped and was accepted, so this is
  propagation, not a new opinion.

  home.html is NOT in the loader list: its footer already passes, via that same technique. Adding this would
  be a second rule for a solved case.

  THE SEPARATORS. Make the anchors 44px inline-flex boxes and leave the `·` spans on the old baseline and the
  row reads ragged — a tidy 44px row that looks broken is not a fix. The container is given the flex so the
  dots ride the same centre line. `:has()` is how a container is selected without touching nineteen files'
  markup; where it is unsupported (an old Android WebView) the container rule is simply ignored and the
  anchors still get their 44px box. It degrades to "slightly uneven but tappable", never to "broken".
*/

/* The row itself — any footer div that directly contains the Privacy link is the legal row. */
footer div:has(> a[href*="privacy"]),
footer address:has(> a[href^="mailto:"]) {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
}

/* The controls. Named by destination because these anchors carry no class of their own — and deliberately
   NOT `footer a`, which would catch the brand link. Growing the logo moves the header, and that stays. */
footer a[href*="about"],
footer a[href*="partner"],
footer a[href*="privacy"],
footer a[href*="terms"],
footer a[href*="refund"],
footer a[href*="data-retention"],
footer a[href*="acceptable-use"],
footer a[href^="mailto:"] {
  min-height: 44px;
  display: inline-flex;
  align-items: center;
}

/*
  🔴 CORRECTION 2026-09-06 04:4x — THE FIRST VERSION OF THIS FILE MISSED login.html ENTIRELY, and my own
  measurement agreed with it because it used the same wrong selector.

  Every rule below was scoped to `footer …`. **`login.html` has no `<footer>` element** — its legal row is a
  `div.auth-left__footer` inside the brand panel. So the stylesheet was linked from that page, loaded on that
  page, and matched NOTHING on it: `min-height: 0px`, `display: inline`, links still ~15px tall.

  🔑 And the part worth more than the fix: my before/after harness counted `document.querySelectorAll('footer a')`
  — the SAME assumption the CSS made. login.html contributed ZERO links to the "before" count and ZERO to the
  "after" count, so "137 → 0" was true of the pages the selector could see and silently excluded the one it
  could not. **A check that shares its subject's blind spot will always agree with it.** Caught on the LIVE
  site, in a different browser build, only because a separate sweep reported `footerTag: false`.

  The fix is one more container, not a new technique: the same tap-box rule, applied to the row login.html
  actually has.
*/
.auth-left__footer a[href*="about"],
.auth-left__footer a[href*="privacy"],
.auth-left__footer a[href*="terms"],
.auth-left__footer a[href*="refund"],
.auth-left__footer a[href*="data-retention"],
.auth-left__footer a[href*="acceptable-use"],
.auth-left__footer a[href^="mailto:"] {
  min-height: 44px;
  display: inline-flex;
  align-items: center;
}
/*
  🔴 SECOND CORRECTION, same night — MY ROW-FLEX WAS UNHIDING A ROW THAT login.css DELIBERATELY HIDES.

  The version above set `display: flex` on `.auth-left__footer` to keep the `·` separators on the centre
  line. On the footers that is harmless. On `login.html` it was not: **login.css sets that row to
  `display: none` at phone width**, and a `display` declaration cannot "only align things" — it overrode the
  hide. Measured on the merged tree at 390px: the row came back at **132px tall**, and the brand panel grew
  from 83px to 176px. **That is an unannounced layout change to the sign-in page, and I shipped it inside a
  commit whose message said "one more container, not a new technique."**

  🔑 The lesson is narrower and more useful than "be careful": **a rule that only means to ALIGN must not
  set `display`.** `display` is the property that decides whether a thing exists on the screen at all, so
  borrowing it for alignment silently takes a decision that belonged to the page.

  So the separators are aligned WITHOUT touching the row's display: the spans get the same vertical centring
  the anchors have. A hidden row stays hidden; a shown row reads straight.

  (Whether that row SHOULD be hidden on a phone is a separate question and not mine to answer here — on the
  live site today it leaves the sign-in page with ZERO reachable policy links at 390px. Filed for chief.)
*/
.auth-left__footer > span {
  display: inline-flex;
  align-items: center;
  min-height: 44px;
}