/* ==========================================================================
   CIRE child theme - sitewide contrast corrections
   MRT-OUTSTANDING C2: listing-card spec labels fail WCAG AA
   ==========================================================================

   THE DEFECT, MEASURED (2026-08-17, site-qa gate, ground read from rendered
   pixels rather than from CSS):

     rgb(118,120,123) on rgb(254,255,255) at 10.24px  =  4.42:1, needs 4.5:1
     87 instances on the Caribbean homepage, at every one of the six widths.

   It is the single largest error in every homepage gate run.

   WHERE THE COLOUR ACTUALLY COMES FROM. The failing markup is plugin-
   generated (.listing-card__spec-label, FuelIDX), so the instinct is to
   override that selector. That would have been the wrong layer. #76787b
   appears as a literal in exactly three stylesheets in the whole tree -
   cire-luxury.css:64, cire-luxury-extras.css:43 and a comment in
   cire-verticals.css - and in all three it is the DEFINITION of one token:

     :root { --cire-gray-med: #76787b; }

   app.css contains no #76787b and no rgb(118,...) at all. A live probe
   confirmed it rather than assuming it: every text run rendering at
   rgb(118,120,123) on the homepage (55), the listing archive (74) and a
   listing detail page (21) changed colour when --cire-gray-med was
   re-declared in the loaded page. There is not one hardcoded instance.

   So one token carries the entire secondary-text layer, and one token is
   what fails. Overriding ~50 consumer selectors would have been endless,
   drifting, and would still have missed every page type not yet gated.

   THE VALUE. #6d6f72, measured 5.04:1 on white - not a new decision. Nick
   approved this exact substitution on 2026-08-16 for the verticals design
   system, on the recorded reasoning that "#76787b on white is 4.43:1 and
   misses WCAG AA by 0.07; #6d6f72 clears it at no visual cost" (see the
   header of cire-verticals.css). This commit extends the same approved value
   to the Caribbean side, so the site's two design systems finally agree on
   one grey instead of differing by a value nobody can see.

   Measured effect of the token change, per page, at 1440:
     homepage         53 runs  4.43:1 -> 5.04:1   (2 held, see below)
     listing archive  69 runs  4.43:1 -> 5.04:1
                       5 runs  4.10:1 -> 4.67:1   (on the #f7f6f4 filter bar)
     listing detail   20 runs  4.43:1 -> 5.04:1
                       1 run   4.13:1 -> 4.70:1   (on the #f6f7f7 agent panel)
   Every one of them passes AA afterwards. The two light-grey grounds are the
   reason a token was chosen over a flat "make labels charcoal": they were
   failing at 4.10 and 4.13 and nobody had counted them.

   WHY THIS IS ORDER-INDEPENDENT. Enqueue order is the silent killer on this
   platform, and cire-luxury-extras.css re-declares the same token at :root
   while being enqueued late and conditionally (print flyers and the MyLogin
   dashboard, from inside component render - after wp_enqueue_scripts). A
   plain :root here would win on the homepage and lose on the dashboard.
   `html:root` is specificity 0,1,1 against :root's 0,1,0, so it wins on
   specificity and does not care who prints last.
   -------------------------------------------------------------------- */

html:root {
  --cire-gray-med: #6d6f72;
}

/* --------------------------------------------------------------------------
   THE ONE PLACE THE TOKEN IS ON A DARK GROUND - held at its existing value.

   Two text runs on the homepage sit on black: the paragraphs inside
   section.bg-dark (front-page.php:210 - the only .bg-dark in the entire
   theme, PHP and CSS both grepped). They are grey-on-black at 4.74:1, which
   is already an ERROR under Nick's dark-ground law: a dark ground must carry
   white or near-white text, and no grey satisfies that. Darkening the token
   would take them to 4.17:1 - still an error, and measurably worse.

   Re-declaring the token on .bg-dark itself holds those runs byte-identical
   to today. Custom properties inherit, so the nearest declaring ancestor
   wins for every descendant, with no selector guessing and no !important.

   This is deliberate, and it is NOT the fix: the correct repair is white
   text on that band, which clears the dark-ground error outright. That is a
   visible copy-area change on the homepage, outside this unit's brief, and
   is raised for approval separately. Held here so that C2 ships with a
   measured zero regressions.
   -------------------------------------------------------------------- */

.bg-dark {
  /* v1.2.7: EXECUTED the repair the pin above deferred (Nick approved
     2026-08-17 "all approved", black-band item): near-white body text on the
     black band per the dark-ground law. #c3c9cc is the established dark-ground
     body colour (footer standard), ~11:1 on black. */
  --cire-gray-med: #c3c9cc;
}