/**
 * PokerPath — Visual Stability Sprint CSS (v4.19.0)
 *
 * Single consolidated CSS file for the v4.19.0 fixes per ChatGPT's
 * sprint guidance:
 *   - Prefer plugin-rendered markup over CSS overrides where feasible
 *   - Document every CSS rule with a comment explaining its purpose
 *   - Add to a single new file rather than scattering
 *
 * Loaded at priority 1000 from pokerpath-search.php (one tier above
 * pp-layout-fixes.css at 999) so v4.19.0 stabilizers win the cascade
 * against both theme and prior plugin CSS.
 *
 * Visual Hierarchy Rule Set (locked v4.19.0, sprint spec):
 *   GOLD (#d4af37)     = ACTION  — primary buttons, active nav state, CTAs
 *   GREEN              = SYSTEM STATE — success, badges, "Verified", "Happening Soon"
 *   GRAY               = PASSIVE INFO — disabled, secondary metadata, info banners
 *   DARK NAVY (#0a0f1e)= COACH PAGE backgrounds (Design System v1.0)
 *   LIGHT theme        = DEFAULT for non-coach pages (Design System v1.0)
 *
 * v4.20.0 retires this file entirely by owning the nav via child theme
 * or plugin-rendered header. Until then, every rule below is documented
 * so v4.20.0 cleanup can identify what's still needed.
 */

/* ======================================================================
   §1. NAV CLEARANCE — Fix #1 (P0 structural UX failure)
   ======================================================================
   Astra's primary nav is sticky/fixed and overlapped page content
   sitewide. Per ChatGPT: "drifting toward patching" — v4.19.0 ships
   the band-aid; v4.20.0 owns the nav.

   This rule pushes page content below the nav by 140px (was 120px in
   prior memory, bumped to clear nav + suits row from Fix #3).

   Sitewide application — every page, not just homepage. The earlier
   v4.17.x experiments tried scoping to body.home only, but the nav
   overlaps EVERY page, so the fix is sitewide.

   v4.20.0 retires this rule when the plugin/theme owns header layout.
   ====================================================================== */

body .site-content,
body #content,
body .site-main,
body main#primary,
body main#main {
    /* v4.19.2 B7 — bumped from 140px to 180px to fully clear the Astra
       nav at 1360px viewport.
       v4.19.3 Item 2 (per ChatGPT review) — replaced literal 180px with
       clamp() responsive padding for cross-viewport scaling.
       v4.19.4 (per ChatGPT review) — floor raised from 140px to 160px.
       At 1360x896, 12vh ≈ 107px, which would clamp to the floor.
       The 140px floor was the value that caused overlap pre-v4.19.2 —
       reintroducing it with "verify later" is unsafe. 160px keeps the
       compression improvement (still smaller than 180px) AND clears
       the nav reliably at the problem viewport. v4.20.0 retires this
       rule entirely when the plugin/theme owns header layout.
         - Min 160px (small screens — clears nav reliably)
         - Max 180px (large screens — caps to prevent excessive top space)
         - 12vh midpoint scales naturally with viewport height */
    padding-top: clamp(160px, 12vh, 180px);
}

/* Reduce Astra nav z-index from default (often 9999+) to a sane value
   so any elevated dialogs/modals can appear above it when needed. */
.ast-primary-header-bar,
header.ast-primary-header-bar,
.main-header-bar,
header.main-header-bar,
#masthead {
    z-index: 100 !important;
}

/* ======================================================================
   §2. ACTIVE NAV STATE — Fix #2 (P0 wayfinding broken)
   ======================================================================
   Astra's .current-menu-item / .current_page_item default uses a
   filled green box at full nav height. Per ChatGPT: "destroys
   navigation clarity. Structural UX failure, not cosmetic."

   Replace with: 3px gold underline, transparent background. Aligns
   with the GOLD-as-ACTION semantic in the Visual Hierarchy Rule Set.

   Selectors cover all Astra menu structures (primary, mobile, etc.).
   ====================================================================== */

.main-header-menu .current-menu-item > a,
.main-header-menu .current_page_item > a,
.ast-builder-menu .current-menu-item > a,
.ast-builder-menu .current_page_item > a,
.menu-item.current-menu-item > a,
.menu-item.current_page_item > a {
    background: transparent !important;
    background-color: transparent !important;
    color: inherit !important;
    border-bottom: 3px solid #d4af37 !important;
    /* Pull the underline up so it visually attaches to the menu item baseline */
    padding-bottom: 4px !important;
}

/* Defeat any Astra hover/focus filled-background that fights the underline */
.main-header-menu .current-menu-item > a:hover,
.main-header-menu .current_page_item > a:hover,
.menu-item.current-menu-item > a:hover,
.menu-item.current_page_item > a:hover {
    background: transparent !important;
    color: #d4af37 !important;
}

/* ======================================================================
   §3. LOGO SUITS DECORATION — Fix #3 + #6
   ======================================================================
   The site-title pseudo-element approach (.site-title::after) was
   sandwiching ♠ ♥ ♦ ♣ INSIDE hero headline letters at 375px viewport.
   Per spec: kill pseudo-elements, render suits as a dedicated <div>
   via PP_Logo_Decorator (JS DOM injection — see class-pp-logo-decorator.php).

   This block:
   1. NEUTRALIZES any prior pseudo-element rule on .site-title::after
      / .site-title::before that might still be present from v17/v19
      Customizer CSS.
   2. STYLES the new .pp-logo-suits div the decorator injects.
   ====================================================================== */

/* Neutralize legacy pseudo-element decorations (Fix #3 cleanup) */
.site-title::after,
.site-title::before {
    content: none !important;
    display: none !important;
}

/* ----------------------------------------------------------------------
   v4.19.2 B1 + B2 — Flower of Life icon + suits
   ----------------------------------------------------------------------
   v4.19.0/v4.19.1 only had .pp-logo-suits (no flower). Production
   inspection found the JS-DOM-injection approach not landing in DOM
   at all on Astra. v4.19.2 switches to server-side injection via
   Astra `astra_site_branding_markup` filter (primary) with action-
   hook + JS-DOM fallbacks. The decorator emits markup like:

     <div class="pp-logo-wrap">
       <div class="pp-logo-flower" aria-hidden="true">[SVG]</div>
       <div class="pp-logo-text-stack">
         [Astra's original .site-title HTML preserved]
         <div class="pp-logo-suits" aria-hidden="true">♠ ♥ ♦ ♣</div>
       </div>
     </div>

   Flexbox places the flower to the LEFT of the wordmark; suits center
   below. Mobile: flower scales smaller, suits hidden below 480px.
   ---------------------------------------------------------------------- */

.pp-logo-wrap {
    display: inline-flex;
    align-items: center;
    gap: 12px;
}

.pp-logo-text-stack {
    display: inline-flex;
    flex-direction: column;
    align-items: flex-start;
    line-height: 1.2;
}

/* When the wrapper is in place, .site-title sits inside the text-stack
   without its own margin/padding fighting the flexbox layout. */
.pp-logo-text-stack .site-title,
.pp-logo-text-stack .ast-site-identity {
    margin: 0;
    padding: 0;
}

.pp-logo-flower {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    width: 40px;
    height: 40px;
    flex-shrink: 0;
}

.pp-logo-flower svg {
    width: 100%;
    height: 100%;
    display: block;
}

@media (max-width: 768px) {
    .pp-logo-flower {
        width: 28px;
        height: 28px;
    }
    .pp-logo-wrap {
        gap: 8px;
    }
}

/* Suits element styling — preserved from v4.19.0 */
.pp-logo-suits {
    display: block;
    color: #d4af37;
    font-size: 1em;
    letter-spacing: 14px;
    line-height: 1.4;
    margin-top: 4px;
    text-align: left;
    max-width: 100%;
    overflow: hidden;
}

/* Hide suits below 480px viewport — per spec, "better hidden than
   broken" if mobile space is too tight. Flower stays visible at
   smaller scale per B2 spec ("brand identity should hold even at 375px"). */
@media (max-width: 479px) {
    .pp-logo-suits {
        display: none !important;
    }
}

/* ======================================================================
   §4. VERIFY BANNER — passive info, GRAY (Visual Hierarchy Rule Set)
   ======================================================================
   The accuracy/verify notice was previously styled as a prominent
   colored banner. Per Rule Set: passive info = gray. Keep visible
   but de-emphasized so it doesn't compete with primary actions.

   Note: Fix #4 also moves this banner DOWN the search wrap via the
   Rule 4 exception edit in class-pp-shortcodes.php. The position
   change is structural; this rule handles the visual de-emphasis.
   ====================================================================== */

.pp-search-wrap .pp-accuracy-notice {
    background: #f3f4f6;
    color: #4b5563;
    border: 1px solid #e5e7eb;
    border-left: 3px solid #9ca3af;
    border-radius: 6px;
    padding: 10px 14px;
    font-size: 13px;
    line-height: 1.4;
    margin-top: 16px;
    margin-bottom: 0;
}

.pp-search-wrap .pp-accuracy-notice strong {
    color: #1f2937;
    font-weight: 600;
}

/* ======================================================================
   §5. SEARCH TOURNAMENTS BUTTON — GOLD (was GREEN, Fix #4 + Rule Set)
   ======================================================================
   Per Visual Hierarchy: gold = ACTION. The primary search button is
   the page's primary action — must be gold, not green. Override the
   .pp-btn-primary green styling for the specific #pp-search-btn.

   v4.19.1 — !important reduction per ChatGPT review:
     KEEP !important: background, color (Astra defeats these with its
                      own !important rules — required to win the cascade).
     REMOVE !important: border, border-color, font-weight (specificity
                        of #pp-search-btn ID selector — (1,0,0) — wins
                        on its own against Astra's class-based rules
                        without !important).

   Selector chain (#pp-search-btn, button#pp-search-btn, .pp-btn-primary#pp-search-btn)
   stays — provides multi-context specificity boosts so the gold wins
   even when the button is rendered inside unusual parent selectors.
   ====================================================================== */

#pp-search-btn,
button#pp-search-btn,
.pp-btn-primary#pp-search-btn {
    background: #d4af37 !important;       /* KEEP — defeats Astra .pp-btn-primary background */
    color: #0a0f1e !important;            /* KEEP — defeats Astra .pp-btn-primary color */
    border: 1px solid #d4af37;            /* v4.19.1 !important removed — ID specificity wins */
    font-weight: 600;
}

#pp-search-btn:hover,
button#pp-search-btn:hover,
.pp-btn-primary#pp-search-btn:hover {
    background: #e6c34d !important;       /* KEEP — defeats Astra hover background */
    color: #0a0f1e !important;            /* KEEP — defeats Astra hover color */
    border-color: #e6c34d;                /* v4.19.1 !important removed — ID + :hover specificity wins */
}

#pp-search-btn:disabled {
    opacity: 0.6;
    cursor: not-allowed;
}

/* The badge inside the search button stays navy-on-gold / inverted
   against the gold to remain readable */
#pp-search-btn .pp-filter-count {
    background: #0a0f1e !important;       /* KEEP — defeats Astra .pp-filter-count background */
    color: #d4af37 !important;            /* KEEP — defeats Astra .pp-filter-count color */
}

/* ======================================================================
   §6. CLEAR BUTTON — GOLD text (Fix #8)
   ======================================================================
   Existing gray-on-dark "× Clear" button is hard to read. Per Rule
   Set: Clear is a user action → gold text. Keep the secondary
   button styling but bump contrast.
   ====================================================================== */

#pp-clear-btn,
button#pp-clear-btn,
.pp-btn-secondary#pp-clear-btn {
    color: #d4af37 !important;
    font-weight: 500;
}

#pp-clear-btn:hover,
button#pp-clear-btn:hover {
    color: #e6c34d !important;
    background: rgba(212, 175, 55, 0.08) !important;
}

/* ======================================================================
   §7. "Search & Filter Tournaments" toggle — Fix #7
   ======================================================================
   pokerpath.js injects this button as a green primary CTA at the top
   of the search area. Per Rule Set + Fix #7: it's not a primary
   action (the search button is). De-emphasize on /tournaments/ so
   the filter grid + search button take primary visual weight.

   On mobile this button is the toggle that expands filters — keep
   it visible. On desktop where filters are already open, it can
   stay but de-emphasized.
   ====================================================================== */

.pp-search-filter-btn {
    /* Was solid green; now neutral outlined button — passive look */
    background: transparent !important;
    color: #4b5563 !important;
    border: 1px solid #d1d5db !important;
    font-weight: 500;
}

.pp-search-filter-btn:hover {
    background: #f9fafb !important;
    color: #1a202c !important;
    border-color: #9ca3af !important;
}

/* When the panel is OPEN, the button label is "Close Filters" — give
   it a slight gold accent to indicate it's the active toggle */
.pp-search-filter-btn[aria-expanded="true"] {
    color: #d4af37 !important;
    border-color: #d4af37 !important;
}

/* ======================================================================
   §8. SORT + ACTIONS INLINE — Fix #4 visual layout
   ======================================================================
   Hide the legacy .pp-mobile-filter-toggle (replaced by JS-injected
   .pp-search-controls). Style the .pp-filter-actions row so Search
   Tournaments + Clear sit cleanly on one line at the bottom of the
   filter grid.
   ====================================================================== */

.pp-filters .pp-mobile-filter-toggle,
#pp-mobile-filter-toggle {
    display: none !important;
}

.pp-filter-actions {
    display: flex;
    flex-wrap: wrap;
    gap: 10px;
    align-items: center;
    margin-top: 16px;
}

@media (max-width: 768px) {
    .pp-filter-actions {
        flex-direction: column;
        align-items: stretch;
    }
    .pp-filter-actions > .pp-btn {
        width: 100%;
    }
}

/* ======================================================================
   §9. MONTH-FORWARD PILL — Fix #5 (informational, non-removable)
   ======================================================================
   The "Showing: April 2026 forward" pill is rendered into
   #pp-active-filters by the new pp-tournaments-month-pill.js. Style
   distinctly from removable filter chips: gold border, no × icon,
   cursor: default.
   ====================================================================== */

.pp-month-pill {
    display: inline-flex;
    align-items: center;
    gap: 6px;
    padding: 5px 12px;
    background: rgba(212, 175, 55, 0.08);
    color: #d4af37;
    border: 1px solid #d4af37;
    border-radius: 999px;
    font-size: 13px;
    font-weight: 500;
    cursor: default;
    user-select: none;
    margin-right: 8px;
    margin-bottom: 8px;
}

.pp-month-pill:hover {
    /* Stays static — no hover effect on a non-interactive informational pill */
    background: rgba(212, 175, 55, 0.08);
    color: #d4af37;
}

/* ======================================================================
   §10. HOMEPAGE LIGHT-THEME COMPATIBILITY (carries from v4.18.x)
   ======================================================================
   Re-affirm light theme on body.home as default. The v4.18.x rules
   in pp-layout-fixes.css §6 already do this; this section just
   confirms no v4.19.0 rule above accidentally re-introduces dark
   theme on the homepage. Add a defensive backstop.
   ====================================================================== */

body.home {
    background: #ffffff;
    color: #1a202c;
}

/* ======================================================================
   §11. v4.19.2 B5 + B6 — Hide redundant "Search & Filter Tournaments"
        header on /tournaments/ and /poker-tours/
   ======================================================================
   pokerpath.js dynamically injects a `.pp-search-filter-btn` (label
   "Search & Filter Tournaments") inside `.pp-search-controls` on every
   page with `[pp_search]`. On /tournaments/ and /poker-tours/, this
   button is redundant — page context is already clear from the URL +
   active nav state, and the filter inputs are useful directly without
   a toggle.

   pokerpath.js is Rule-4 locked, so we hide via CSS body-class
   targeting. Filter panel is force-shown (defeats the
   pp-filters-collapsed state pokerpath.js applies on page load) so
   users still get the controls without the redundant toggle.

   On the homepage, [pp_home_hero] handles its own toggle behavior
   (force-expand on desktop, mobile collapsible). Those pages keep
   the button.
   ====================================================================== */

/* ============================================================
   v4.20.0 RETIRE: Remove when nav/search owned
   ------------------------------------------------------------
   This rule hides the "Search & Filter Tournaments" header on
   /tournaments/ and /poker-tours/. It exists because pokerpath.js
   is byte-locked under Rule 4 and we cannot fix the JS that
   adds the button.

   When v4.20.0 ships nav ownership (child theme or plugin
   header), this rule retires entirely because the markup
   never gets rendered in the first place.
   ============================================================ */
body.page-tournaments .pp-search-controls .pp-search-filter-btn,
body.page-poker-tours  .pp-search-controls .pp-search-filter-btn,
body.page-tours        .pp-search-controls .pp-search-filter-btn {
    display: none !important;
}

/* ============================================================
   v4.20.0 RETIRE: Remove when nav/search owned
   ------------------------------------------------------------
   This rule force-shows the filter panel on /tournaments/ and
   /poker-tours/ regardless of pokerpath.js's pp-filters-collapsed
   default. It exists because pokerpath.js is byte-locked under
   Rule 4 and adds the collapsed class on every page load — once
   we hide the toggle button (above), users would have no way
   to expand the panel without this counter-rule.

   When v4.20.0 ships nav ownership (child theme or plugin
   header), pokerpath.js is no longer the source of truth for
   the search panel — this counter-rule retires entirely.
   ============================================================ */
body.page-tournaments .pp-filters.pp-filters-collapsed .pp-filter-grid,
body.page-tournaments .pp-filters.pp-filters-collapsed .pp-filter-actions,
body.page-tournaments .pp-filters.pp-filters-collapsed .pp-active-filters,
body.page-poker-tours  .pp-filters.pp-filters-collapsed .pp-filter-grid,
body.page-poker-tours  .pp-filters.pp-filters-collapsed .pp-filter-actions,
body.page-poker-tours  .pp-filters.pp-filters-collapsed .pp-active-filters,
body.page-tours        .pp-filters.pp-filters-collapsed .pp-filter-grid,
body.page-tours        .pp-filters.pp-filters-collapsed .pp-filter-actions,
body.page-tours        .pp-filters.pp-filters-collapsed .pp-active-filters {
    display: revert !important;
}

/* ======================================================================
   v4.20.0 DEPRECATION NOTE
   ======================================================================
   Every rule above is a workaround for layered DOM ownership issues.
   v4.20.0 owns the nav via child theme or plugin-rendered header,
   which makes §1 (nav clearance) and §2 (active state) obsolete.

   When v4.20.0 ships:
   - Delete §1, §2 entirely (nav layout owned by plugin/theme)
   - Re-evaluate §7, §11 (filter button override + page-class hide) —
     pokerpath.js may be rewritten or the button may be rendered
     server-side, making CSS workarounds unnecessary
   - §3-§6, §8, §9, §10 likely stay as they're plugin-shortcode-side
     concerns, not nav concerns
   ====================================================================== */

/* ======================================================================
   §13. v4.19.5 Fix #3 — Pills above action buttons (founder override)
   ======================================================================
   Founder override on Phase -1 Decision 7 conflict acknowledged and on
   the record per the v4.19.5 brief. Strategic objection — that this
   polishes elements (.pp-recent-btn, "California" chip, Sort By/Order)
   marked for elimination/demotion in the eventual rebuild — is noted
   but not re-litigated here. Interim polish on furniture scheduled for
   replacement.

   APPROACH: make .pp-filters a column-direction flex container, then
   use `order` on each child to put chips between filter-grid and
   filter-actions. The literal "same row as Sort By/Order" goal is not
   achievable CSS-only (Sort By + Order live INSIDE .pp-filter-grid as
   nested .pp-filter-group items; chips are sibling DIVs outside the
   grid). This delivers the founder spec's fallback: chips above the
   action buttons.

   PILL GROUPING PRESERVED: Quick chips (.pp-search-presets) stay as
   one group; Recent chips (.pp-recent-searches) stay as one group;
   the "Recent:" label stays inside its container.
   ====================================================================== */

.pp-filters {
    display: flex;
    flex-direction: column;
}

.pp-filters > .pp-mobile-filter-toggle  { order: 0; }   /* mobile toggle stays at top */
.pp-filters > .pp-filter-grid           { order: 1; }   /* filter dropdowns (Sort By + Order moved OUT in v4.19.6) */
.pp-filters > .pp-filter-actions        { order: 2; }   /* v4.19.6 — action row above chips, per v4 mockup */
.pp-filters > .pp-search-presets        { order: 3; }   /* v4.19.6 — Quick chips BELOW action row */
.pp-filters > .pp-recent-searches       { order: 4; }   /* v4.19.6 — Recent chips below Quick chips */
.pp-filters > .pp-active-filters        { order: 5; }   /* Active filter chips after a search */

/* ======================================================================
   §14. v4.19.5 Fix #2A — Aasta nav height shrink (logo cap)
   ======================================================================
   Production runs Aasta theme. Aasta's nav height is logo-driven:
   customizer-set max-width (default 224px) with height:auto produces a
   ~92px-tall logo image, plus Bootstrap navbar padding (8px top + 8px
   bottom) plus navbar-brand padding (5px top + 5px bottom) = ~118px
   total nav height. (Verified by inspecting Aasta v13.5 source:
   theme-default.css and style.css have NO height/padding rules on
   .navbar — only the customizer's inline max-width/height:auto on
   .custom-logo drives the size.)

   APPROACH: cap the logo's max-height so the navbar naturally shrinks
   to fit. Bootstrap's flex layout re-flows automatically when the
   tallest child shrinks.

   Math:
     navbar_height = 26 + logo_height
     For 70px nav: logo_height = 44px (desktop max-height)
     For 56px nav (mobile): logo_height = 30px

   SPECIFICITY: my selector (.navbar.navbar-header-wrap img.custom-logo,
   0,3,1) beats Aasta's inline rule (.navbar img.custom-logo,
   0,2,1). Aasta sets max-width + height:auto; I add max-height.
   Browser respects all three constraints and scales the image
   proportionally — both width AND height stay within their caps.
   NO !important needed.

   This rule does NOT modify any Aasta theme files. If Aasta is later
   updated, this override continues to work as long as the Aasta logo
   markup keeps using <img class="custom-logo"> inside .navbar
   (standard WordPress custom_logo() output — extremely stable).
   ====================================================================== */

/* v4.19.7 TIGHTEN — Production verification (2026-04-29) showed v4.19.6
   nav landed at 130px (down from 118px pre-deploy, but well above the
   ~80px target). The brand mark was rendering at 280x60 (max-height: 60
   binding). Logo 60 + brand-padding 10 + nav-padding 16 = 86 expected,
   but actual was 130 — the extra ~44px came from nested Bootstrap
   .row / .navbar-collapse padding that v4.19.6 §17 didn't compress.

   v4.19.7 fix: tighten logo to max-height 50, AND add §17 inner-container
   compression (below). Logo 50 + brand-pad 10 + nav-pad 16 = 76 expected.
   Mobile: max-height 32 → 32+10+12 = 54. Both close to founder targets. */
.navbar.navbar-header-wrap img.custom-logo {
    max-width: 280px;
    max-height: 50px;
}

@media (max-width: 768px) {
    .navbar.navbar-header-wrap img.custom-logo {
        max-width: 200px;
        max-height: 32px;
    }
}

/* ======================================================================
   §15. v4.19.5 Fix #2B — Aasta page content top clearance
   ======================================================================
   Aasta's page.php / archive.php / single.php / search.php all wrap page
   content in <section class="theme-block theme-blog ..."> with default
   padding-top: 5rem (80px) from style.css line 700-703.

   With Aasta's nav at position:absolute (top=13, ~118px tall extending
   to y=131), the 80px theme-block padding-top puts content at y=80
   while nav extends to y=131. The hero h1 is at top=73 in production,
   inside .theme-block's padding zone — visible BENEATH the nav.

   §1 above (clamp 160-180px on .site-content / #content / .site-main /
   main#primary / main#main) was written for Astra's wrapper class names.
   AASTA DOES NOT RENDER any of those wrappers — Aasta uses .theme-block,
   .post-content, .entry-content (Bootstrap-style markup). §1 has been
   silently no-op on production since Aasta was activated.

   FIX: override .theme-block's padding-top with a value calibrated for
   the now-70px nav (post-§14). Targets first .theme-block on the page
   to avoid pushing down secondary sections (testimonials, CTAs etc.)
   that may use the same class on themed homepages.

   SPECIFICITY: my selector (body section.theme-block:first-of-type,
   0,2,2) beats Aasta's bare .theme-block (0,1,0). NO !important needed.

   Calibration:
     Desktop nav post-§14: ~70px
     Desktop padding-top: clamp(95px, 8vh, 110px) = 70px nav + 25-40px breathing
     Mobile nav post-§14: ~56px
     Mobile padding-top: clamp(76px, 10vh, 90px) = 56px nav + 20-34px breathing

   §1 is left unmodified. If Path B (Astra parent + child theme) is
   later activated, §1's existing selectors will match Astra's markup
   and provide nav clearance there — §15 only fires on Aasta's
   .theme-block markup. The two rules are non-overlapping by selector.
   ====================================================================== */

/* v4.19.7 RECALIBRATION — Founder spec: tighten gap below nav to ~12px.

   v4.19.6 RECAP — Production DOM verification (2026-04-29) confirmed:
   - Customizer Additional CSS contains `html body.home .pp-hero
     { padding-top: 60px }` at specificity 0,2,2.
   - My v4.19.6 §15 used `body.home .pp-hero` at specificity 0,2,1 — LOST.
   - Result: §15 was silently no-op for 24h post-deploy.

   v4.19.7 FIX — Two changes:
   1. Bump specificity to `html body.home .pp-hero` (0,2,2) — ties Customizer.
      To break the tie, my rule loads from pp-v4-19-fixes.css enqueued at
      priority 1000 (very late). Customizer's wp-custom-css inline `<style>`
      typically loads even later in <head>. So specificity-tie + cascade
      order alone won't reliably win. Therefore: !important on padding-top.
   2. Replace clamp() with fixed values calibrated for the (projected)
      post-§17 nav of ~80px desktop / ~62px mobile, plus 12px gap:
        Desktop padding-top = 80 + 12 = 92px
        Mobile  padding-top = 62 + 12 = 74px

   ASSUMPTION: §17 actually shrinks the nav to ~80px desktop. v4.19.6's §17
   only got nav from 118px to 130px on production (some Bootstrap row /
   navbar-collapse internal padding still contributing height). v4.19.7 §17
   adds inner-element compression to actually reach ~80px. If post-deploy
   measurement shows nav landing at, say, 100px instead, §15's 92px gives
   8px-clipped hero. Per founder direction: ship best projection, recalibrate
   one-line v4.19.7-r2 if measurement diverges.

   !important is JUSTIFIED here: Customizer Additional CSS rule has equal
   specificity AND loads later in cascade. No clean specificity-only path.
   Bounded to padding-top property only. */
/* v4.19.7-r2 — DOM verification post-v4.19.7 deploy showed Customizer
   Additional CSS has `html body.home .pp-hero { padding-top: 60px
   !important }` at specificity 0,2,2 + !important. v4.19.7 §15 used the
   identical selector, identical specificity (0,2,2), identical !important.
   When BOTH have !important AND tie on specificity, cascade order wins —
   Customizer's <style id="wp-custom-css"> loads later, so Customizer won.
   v4.19.7 §15 was silently no-op for ~24h post-deploy.
   Fix: bump specificity to 0,3,2 via the double-class trick
   `.pp-hero.pp-hero` (CSS allows the same class repeated; each instance
   counts toward specificity). This beats Customizer's 0,2,2.
   Value recalibrated: with v4.19.7-r2 Fix B nav at ~76px (down from 120),
   hero clearance = nav + 12 gap = 88px desktop / 72px mobile. */
/* v5.5.8 — NEUTRALIZED; superseded by consolidated Fix 6 region in
   pokerpath.css (v5.5.5-fix1 lineage, cascade-consolidated in v5.5.8
   per ChatGPT Gate 6 Strategy B ruling). The Fix 6 winning rule now
   uses higher-specificity selector `html body.home main.site-main
   .pp-hero` (0,4,3) and locked values 180/212/145/191 per state.
   Comment-out preserved here for cascade-archaeology paper trail.
html body.home .pp-hero.pp-hero {
    padding-top: 88px !important;
}

@media (max-width: 768px) {
    html body.home .pp-hero.pp-hero {
        padding-top: 72px !important;
    }
}
*/

/* ======================================================================
   §16. v4.19.6 Fix #4 — Action row layout (Sort + Order + Search + Clear)
   ======================================================================
   Companion to the v4.19.6 markup edit in class-pp-shortcodes.php that
   moved Sort By + Order out of .pp-filter-grid into .pp-filter-actions.
   This rule lays them out as a single horizontal row on desktop and
   wraps gracefully on tablet / mobile.

   Layout (desktop, ≥769px):
     [Sort By dropdown] [Order dropdown] [Search button — fills space] [Clear]
   Layout (tablet 481-768px):
     [Sort By]    [Order]
     [Search Tournaments — full row]   [Clear]
   Layout (mobile ≤480px):
     [Sort By]
     [Order]
     [Search Tournaments]
     [Clear]

   The .pp-filter-group label inside .pp-filter-actions needs different
   styling from when it lived in .pp-filter-grid (no grid cell, narrower
   layout) — minimal overrides applied below.
   ====================================================================== */

.pp-filter-actions {
    display: flex;
    flex-wrap: wrap;
    gap: 12px;
    align-items: flex-end;          /* labels above selects align label baselines */
    margin-top: 16px;
}

/* Sort By + Order — when nested INSIDE .pp-filter-actions (post-v4.19.6
   markup edit). Compact width so they share the row with buttons. */
.pp-filter-actions > .pp-filter-group.pp-filter-sort {
    flex: 0 1 auto;
    min-width: 140px;
    margin: 0;                      /* defeat any inherited grid-cell margin */
}

.pp-filter-actions > .pp-filter-group.pp-filter-sort label {
    display: block;
    margin-bottom: 4px;
}

.pp-filter-actions > .pp-filter-group.pp-filter-sort select {
    width: 100%;
}

/* Search Tournaments grows to fill remaining space; Clear stays compact. */
.pp-filter-actions > #pp-search-btn {
    flex: 1 1 220px;
    min-height: 38px;
}

.pp-filter-actions > #pp-clear-btn,
.pp-filter-actions > #pp-share-search-btn {
    flex: 0 0 auto;
    min-height: 38px;
}

/* Tablet: drop Search/Clear to second row but keep Sort + Order paired. */
@media (max-width: 768px) and (min-width: 481px) {
    .pp-filter-actions > .pp-filter-group.pp-filter-sort {
        flex: 1 1 calc(50% - 12px);
    }
    .pp-filter-actions > #pp-search-btn {
        flex: 1 1 100%;
    }
}

/* Mobile: stack everything full-width. */
@media (max-width: 480px) {
    .pp-filter-actions > .pp-filter-group.pp-filter-sort,
    .pp-filter-actions > #pp-search-btn,
    .pp-filter-actions > #pp-clear-btn {
        flex: 1 1 100%;
    }
}

/* ======================================================================
   §17. v4.19.6 Fix — Aasta nav height shrink via nav-link padding
   ======================================================================
   DOM verification on production (2026-04-28, 1440x900 viewport, logged-in
   admin) revealed:
   - The nav is 118px tall NOT because of logo height (no logo uploaded yet)
   - It's because .nav-link computes to padding-top: 45.008px (= 2.8125rem)
     plus 4px bottom + 28px line-height ≈ 80px nav-link, which the LI
     stretches to 118px via flex container alignment.

   The 45.008px source is NOT in any matchedCSSRules I queried. Bootstrap
   declares 0.5rem (8px). Smartmenus declares 0px. Yet computed is 45.008.
   Most likely culprit: bootstrap-smartmenus.js or jquery.smartmenus.js
   sets it inline at runtime via JS for visual menu alignment, AND the
   inline style isn't visible to my static-rule introspection. I cannot
   identify the exact rule statically.

   Therefore: !important is JUSTIFIED on this override. Without it, my
   static CSS rule loses to a JS-injected inline style. Bounded to:
   nav.navbar .nav-link padding properties only. Documented for the next
   developer so this doesn't propagate.

   Target nav height (post-§14 logo cap + this padding override):
     Desktop: ~80px (logo brand mark 60px tall + 8px navbar padding each)
     Mobile:  ~60px (logo brand mark 36px tall + 8px navbar padding each)

   Specificity: nav.navbar .nav-link (0,2,2) - matches Bootstrap's
   .nav-link (0,1,0) at higher specificity. !important defeats the
   suspected JS-injected inline style. */

nav.navbar .nav-link {
    padding-top: 12px !important;
    padding-bottom: 12px !important;
}

@media (max-width: 991px) {
    nav.navbar .nav-link {
        padding-top: 10px !important;
        padding-bottom: 10px !important;
    }
}

/* Bound the navbar's own padding so vertical centering is consistent. */
nav.navbar.navbar-header-wrap {
    padding-top: 8px;
    padding-bottom: 8px;
}

/* v4.19.7 ADD — Aasta wraps the nav contents in nested Bootstrap layout:
     nav.navbar > div.container > div.row > div.collapse.navbar-collapse > ul.nav
   v4.19.6 §17 only compressed the outermost (nav-link padding). DOM trace
   on production showed div.container at 114px tall while nav was 130px —
   the extra height came from row/navbar-collapse default padding/min-height.
   Compress all the inner layers. */
nav.navbar.navbar-header-wrap .container,
nav.navbar.navbar-header-wrap .row,
nav.navbar.navbar-header-wrap .row.align-self-center,
nav.navbar.navbar-header-wrap .collapse.navbar-collapse,
nav.navbar.navbar-header-wrap .nav.navbar-nav,
nav.navbar.navbar-header-wrap .menu-item {
    padding-top: 0 !important;
    padding-bottom: 0 !important;
    min-height: 0 !important;
}

/* v4.19.7-r2 ADD — DOM verification post-v4.19.7 deploy showed `.navbar-brand`
   computed `padding-top: 24px; padding-bottom: 30px` (54px total) — the
   missing 54px height contributor that v4.19.7 §17 inner compression didn't
   reach. The 24/30 values are NOT in any CSSOM-introspectable rule
   (Bootstrap declares 5px, smartmenus declares 6px — both invisible to
   computed override). Most likely smartmenus jQuery plugin setting it via
   `el.style.setProperty()` at runtime, OR a cross-origin stylesheet rules
   CORS-blocked from CSSOM enumeration. Either way: !important in CSS
   beats both runtime inline-without-!important and unreachable rules.
   Set to 5px each (Bootstrap natural default) for breathing room around
   the logo. Math after v4.19.7-r2: brand cell = 5+50+5 = 60, nav padding
   = 8+8 = 16, total nav = 76px. Down from v4.19.7's 120px. */
nav.navbar.navbar-header-wrap .navbar-brand,
nav.navbar.navbar-header-wrap a.navbar-brand {
    padding-top: 5px !important;
    padding-bottom: 5px !important;
}

/* ======================================================================
   §18. v4.19.6 Fix — Hero text styling (Playfair Display + gold gradient)
   ======================================================================
   Production DOM verification (2026-04-28) showed .pp-hero-title currently
   renders in:
     font-family: Cinzel, serif
     color: rgb(245, 240, 232) [off-white]
     font-weight: 700
     font-style: normal (good — no italic to remove)

   v4 mockup specifies:
     font-family: Playfair Display
     color: shiny gold gradient (4-stop linear)
     font-weight: 500
     font-style: normal

   Source of the existing Cinzel + off-white styling is unknown to me
   statically — either Customizer Additional CSS or page 488 inline style.
   v4.19.6 plugin CSS uses bumped specificity body.home .pp-hero
   .pp-hero-title (0,3,2) to win over most likely rule sources. Plus
   webkit-background-clip: text trick to render the gradient as text fill.

   pokerpath-search.php enqueues Playfair Display from Google Fonts at
   priority 998 (before pp-v4-19-fixes.css at 1000) so the font is loaded
   when this rule applies it. */

/* v4.19.7 BUMP — DOM verification (2026-04-29) showed Customizer
   Additional CSS contains `.pp-hero-title { color: #F5F0E8; font-family:
   Cinzel, serif; font-weight: 700 }` AND likely a higher-specificity
   variant (`html body.home .pp-hero .pp-hero-title`) winning over my
   v4.19.6 §18.
   Selector bumped to `html body.home .pp-hero .pp-hero-title` (0,3,3),
   plus !important on font-family / font-weight / -webkit-text-fill-color
   to defeat any inline-style or !important Customizer is using.
   Bounded !important — only on the four specific properties losing the
   cascade. background-clip and gradient fill stayed without !important
   because v4.19.6 confirmed they DID apply (background-clip: text was
   visible on the computed style). */
html body.home .pp-hero .pp-hero-title {
    font-family: 'Playfair Display', Georgia, 'Times New Roman', serif !important;
    font-weight: 500 !important;
    font-style: normal;
    /* Gradient fill via background-clip: text trick. */
    background: linear-gradient(180deg, #fbe28a 0%, #e6c34d 35%, #d4af37 65%, #9c771a 100%);
    -webkit-background-clip: text;
    background-clip: text;
    -webkit-text-fill-color: transparent !important;
    color: transparent !important;
    letter-spacing: 0.5px;
    line-height: 1.15;
    margin: 0 0 14px;
    font-size: clamp(28px, 4.5vw, 48px);
}

/* The <em> wrap around "Tournament" was removed in v4.19.6 page 488 edit,
   but defensive: if anything reintroduces <em>, neutralize the italic. */
html body.home .pp-hero .pp-hero-title em {
    font-style: normal !important;
    font-weight: inherit;
}

/* Hero subtext below the title — match mockup's quiet gray. */
html body.home .pp-hero .pp-hero-sub {
    color: #888 !important;
    font-size: 14px;
    margin: 0;
    line-height: 1.5;
}

/* ======================================================================
   §19. v4.19.7 — Move "Close Filters" + "Sort: Soonest first" bars BELOW
   the search block (Items 3 + 4 of the v4.19.7 patch)
   ======================================================================
   v5 mockup spec: the two action bars (Close Filters and Sort: ...) should
   appear AFTER the search filter block, not before it.

   Production DOM (verified 2026-04-29):
     <div class="pp-search-wrap">
       <div class="pp-search-controls">         ← contains the two buttons
         <button class="pp-search-filter-btn">Close Filters</button>
         <button class="pp-search-sort-btn">Sort: Soonest first</button>
       </div>
       <div class="pp-filters">                  ← the search block
         <div class="pp-filter-grid">...</div>
         <div class="pp-filter-actions">...</div>
         <div class="pp-search-presets">...</div>
         <div class="pp-recent-searches">...</div>
       </div>
       <div class="pp-accuracy-notice">...</div>
       <div></div>
     </div>

   .pp-search-controls and .pp-filters are SIBLINGS inside .pp-search-wrap.
   Currently rendered in document order: controls (top), filters (below).
   v5 mockup wants them flipped: filters first, controls second.

   APPROACH: make .pp-search-wrap a flex column container, set `order` on
   the children. Pure CSS, no markup change, no shortcodes.php touch
   (byte-lock holds).

   ORDER:
     .pp-filters           → 1  (search block FIRST)
     .pp-search-controls   → 2  (Close Filters + Sort bars AFTER)
     .pp-accuracy-notice   → 3  (verification text last, as before)

   Bonus: style the buttons as full-width bars per the v5 mockup (gold
   border for Close Filters, green border for Sort).
   ====================================================================== */

.pp-search-wrap {
    display: flex;
    flex-direction: column;
}

.pp-search-wrap > .pp-filters         { order: 1; }
.pp-search-wrap > .pp-search-controls { order: 2; }
.pp-search-wrap > .pp-accuracy-notice { order: 3; }

/* Style .pp-search-controls as a stack of full-width bars (vertical list
   below the search block). Default Bootstrap layout has buttons inline;
   we want each as a clearly separated horizontal bar. */
.pp-search-wrap > .pp-search-controls {
    display: flex;
    flex-direction: column;
    gap: 8px;
    margin-top: 14px;
}

.pp-search-wrap > .pp-search-controls > .pp-search-filter-btn,
.pp-search-wrap > .pp-search-controls > .pp-search-sort-btn {
    display: block;
    width: 100%;
    padding: 12px 16px;
    text-align: center;
    font-size: 13px;
    border-radius: 6px;
    cursor: pointer;
}

/* Close Filters bar — gold border, gold text (Visual Hierarchy: gold = action) */
.pp-search-wrap > .pp-search-controls > .pp-search-filter-btn {
    background: transparent;
    border: 1px solid #d4af37;
    color: #d4af37;
}
.pp-search-wrap > .pp-search-controls > .pp-search-filter-btn:hover {
    background: rgba(212, 175, 55, 0.08);
    color: #e6c34d;
    border-color: #e6c34d;
}

/* Sort: Soonest first bar — green border, green text (Visual Hierarchy:
   green = system state, the active sort is a system state indicator) */
.pp-search-wrap > .pp-search-controls > .pp-search-sort-btn {
    background: transparent;
    border: 1px solid #1d9e75;
    color: #1d9e75;
}
.pp-search-wrap > .pp-search-controls > .pp-search-sort-btn:hover {
    background: rgba(29, 158, 117, 0.08);
    color: #2db088;
    border-color: #2db088;
}

/* ======================================================================
   §20. v4.19.8 Item 1 — Delete the "Close Filters" toggle entirely
   ======================================================================
   Phase-1 Decision 7 + v4.19.8 spec: filters are always rendered, always
   visible. No toggle. No hidden state.

   ARCHITECTURE: pokerpath.js (Rule 4 byte-locked, untouched since v4.16.1)
   injects .pp-search-controls with .pp-search-filter-btn ("Close Filters")
   and .pp-search-sort-btn ("Sort: Soonest first") at runtime, AND
   auto-applies .pp-filters-collapsed class to .pp-filters on page load.
   We can't strip the JS without releasing Rule 4 — and we don't need to.

   APPROACH: CSS-only neutralization.
   1. Hide .pp-search-controls entirely (the toggle bar is invisible)
   2. Override .pp-filters-collapsed effect — force-show filter contents
      regardless of whether pokerpath.js's collapse class is applied

   pokerpath.js still binds click handlers vestigially, but a hidden
   element doesn't receive clicks. The toggle logic becomes inert,
   user sees no toggle, filters are always visible.

   v4.19.7 §19 styled .pp-search-controls as gold/green bars below the
   search block. With §20 hiding them, those §19 styles are now also
   inert — kept in place for forward-compat in case the toggle is
   ever reintroduced (e.g., after Path B / theme rewrite where the
   pokerpath.js injection retires entirely).
   ====================================================================== */

.pp-search-wrap > .pp-search-controls,
.pp-search-controls {
    display: none !important;
}

/* Force-show filter contents regardless of pokerpath.js's collapse class.
   Without this, .pp-filters-collapsed (set on initial page load by the JS)
   would hide the filter grid + actions even after we hide the toggle. */
.pp-filters.pp-filters-collapsed > .pp-filter-grid,
.pp-filters.pp-filters-collapsed > .pp-filter-actions,
.pp-filters.pp-filters-collapsed > .pp-search-presets,
.pp-filters.pp-filters-collapsed > .pp-recent-searches,
.pp-filters.pp-filters-collapsed > .pp-active-filters {
    display: revert !important;
}

/* ======================================================================
   §21. v4.19.8 Item 3 — Hide Login/avatar button on mobile
   ======================================================================
   Production verification (real-device screenshots): #pp-nav-user
   (the user-avatar / Login button, position: fixed, top: 12, left:
   1373, z-index: 99999) overlaps the brand mark on mobile (≤768px
   viewports). Hide on mobile; Login access remains via the hamburger
   menu's standard WordPress menu items.

   The element is JS-injected. Hide via CSS works regardless of
   injection source.
   ====================================================================== */

@media (max-width: 768px) {
    #pp-nav-user,
    .pp-nav-user-wrap {
        display: none !important;
    }
}