/* ============================================================
   Serena Psicología — the native header (#25)

   Styles the markup #24 emits (`inc/serena-header.php`). Target: a render
   indistinguishable from the Elementor header it replaces — not a redesign.
   Every number below was measured off the control site with Playwright at
   1280x900 and 390x844; where a value looks arbitrary it is because the thing
   it reproduces was arbitrary, and the comment says which one.

   ## What this file is NOT

   It is not a re-scope of `header-modern.css`, and that file stays where it is,
   unchanged and still enqueued. `header-modern.css` is scoped to
   `.elementor-location-header`, which exists exactly when SERENA_NATIVE_CHROME
   is OFF — i.e. what production serves today and what a rollback returns to.
   Deleting or re-pointing it would mean switching the flag off no longer
   restores today's rendering, and F3's whole safety property is "rollback is
   switching the flag off, not a deploy".

   Nothing is duplicated: the two files address DOMs that never coexist.
   `.elementor-location-header` only exists with the flag off, `.serena-header`
   only with it on. What IS shared is the intent — the palette, the animated
   underline, the hover pill, the open-panel shadow, the <=1024px one-row items
   — and those are re-expressed here on the native selectors. F5 deletes
   Elementor and `header-modern.css` with it; this file survives.

   ## `style.css` is untouchable

   The child theme's `style.css` is a compiled artefact whose 19 Sass partials
   are not in the repo and whose `.map` carries no `sourcesContent`. `.clean-list`
   (`list-style:none; margin-left:0`) lives in there. It is hooked, never
   redefined.

   Palette: coral #FF9472 · gold #FFBC02 · magenta #B11972 · ink #4F4F4F
   ============================================================ */

.serena-header {
	--sc-coral: #ff9472;
	--sc-gold: #ffbc02;
	--sc-magenta: #b11972;
	--sc-ink: #4f4f4f;
	/* Submenu link ink and the hamburger grey, both measured off the control. */
	--sc-link: #303030;
	--sc-toggle: #9d9d9d;

	/*
	 * The nav's padding. Declared FIRST because the bar's height is computed
	 * from it.
	 *
	 * Three things depend on it and none of them may drift: the nav's own
	 * padding, the bar's height below, and the top of the mega-menu panels —
	 * the control hangs those off the nav's CONTENT-box bottom, which is
	 * exactly this much above the bar's padding box.
	 */
	--sc-nav-pad: 10px;

	/*
	 * The two quantities a top-level item is made of. Declared here, and USED
	 * below — `.serena-header__title` for the padding, `.serena-header__title-text`
	 * for the line-height — so that neither can be edited out of step with the
	 * bar's height.
	 */
	--sc-title-lh: 25.5px;
	--sc-title-pad-y: 10px;

	/*
	 * The bar's height, and the only place it is written down.
	 *
	 * It is not a design decision, it is arithmetic all the way down: an item is
	 * `--sc-title-pad-y` + `--sc-title-lh` + `--sc-title-pad-y` = 45.5px tall,
	 * and the nav sits in `--sc-nav-pad` above and below it. 45.5 + 20 = 65.5.
	 *
	 * ⚠ Two rounds of the same defect, both worth keeping visible.
	 *
	 * It first read `65.5px` flat, while the comment on the panels' `top` claimed
	 * the two were bound "by construction". They were not: with the literal,
	 * `--sc-nav-pad: 12px` gave nav padding 12, bar height 65.5, and a panel top
	 * 2px off the nav's content-box bottom. Measured, not argued.
	 *
	 * Then it read `calc(45.5px + 2 * var(--sc-nav-pad))`, which LOOKS derived
	 * and is half derived: `45.5px` was still a literal standing in for two
	 * declarations sitting sixty lines below, and editing either of them would
	 * have desynchronised the bar and, through it, all three panels — the very
	 * failure the paragraph above describes. Worse, the negative control offered
	 * as proof (`--sc-bar-h: 65.5px` -> 0 AE) proved nothing: `45.5 + 2*10 == 65.5`
	 * is a tautology, and a tautology measures 0 whether or not anything is bound.
	 *
	 * A DERIVATION THAT STOPS ONE LEVEL SHORT LOOKS EXACTLY LIKE A DERIVATION.
	 * The test is not whether the arithmetic is visible, it is whether changing
	 * an input moves the output — which is why this one is mutation-tested (see
	 * the note on the panels' `top`) rather than read.
	 */
	--sc-bar-h: calc(var(--sc-title-lh) + 2 * var(--sc-title-pad-y) + 2 * var(--sc-nav-pad));

	/*
	 * The width of the panels' content box — the site's boxed container width.
	 *
	 * ⚠ This one is ABSOLUTE, and that is a measurement, not a reading of the
	 * code. At 1280 the control's content box is 1180px and a full-bleed panel
	 * with 50px of side padding is ALSO 1180px: two different rules landing on
	 * the same pixel, which is precisely the trap #38 describes. The matrix
	 * captures one desktop width, so it cannot tell them apart in either
	 * direction.
	 *
	 * So the control was measured at four widths instead of argued about:
	 *
	 *   vw 1100 -> content 1100 (x=0)     vw 1440 -> content 1180 (x=130)
	 *   vw 1280 -> content 1180 (x=50)    vw 1600 -> content 1180 (x=210)
	 *
	 * Constant above 1180 and shrinking below it: `min(100%, 1180px)`, centred.
	 * The side padding is therefore DERIVED from it rather than written as 50px,
	 * which was only ever the right answer at 1280.
	 *
	 * ⚠ HOW STRONG THIS EVIDENCE IS, stated because it is easy to overstate.
	 * The matrix does NOT verify this. It captures one desktop width, and at
	 * that width the derived form and the fitted `50px` are the same pixel —
	 * reverting to the literal scores 0 AE, measured, so the gate is not merely
	 * silent here, it is incapable. The only evidence is the four-width sweep
	 * above, taken by hand in one state (`panel-areas`) on one route.
	 *
	 * That is real evidence and it is why this is written as an expression. It
	 * is not gate-verified, and the same caveat covers the other two
	 * declarations whose negative controls come out mute — `justify-content`
	 * below, and `--sc-bar-h` in the token block. Three of the declarations
	 * carrying "derived, not fitted" are exactly the three the gate cannot
	 * discriminate. Saying "verified" of any of them would be the polite form of
	 * the fabricated green.
	 */
	--sc-panel-content-w: 1180px;

}

/* ============================================================
   1. The bar, and the 26px of document flow it is allowed to occupy

   This block is the whole point of the issue. Before it, every page was
   1545px (desktop) / 1394px (mobile) taller than the control, because the
   three mega-menu panels rendered expanded, in flow.

   Two things put the flow back:

   - the panels leave the flow entirely (section 5), and
   - the bar occupies EXACTLY the 26px the Elementor header occupied.

   That 26px is not a round number someone chose. Elementor's header root is
   an `inline-block` with `vertical-align:middle` whose own height collapses to
   0 (its bar carries `margin-bottom:-70px`), so what it actually contributed to
   the document was the *line box* it sat in — body's strut, `16px/26px`
   Open Sans, measured at 26.000px with its baseline 19.000px down. The bar was
   then painted hanging off that baseline at y=14.719.

   Reproducing that arithmetic instead of the mechanism would mean hardcoding
   14.719px, a number made of font metrics. So the mechanism is reproduced
   instead: the same atomic inline, the same `vertical-align`, and a
   margin-bottom that cancels the height so the margin box is 0 tall — which is
   what made Elementor's root 0 tall too. The browser then re-derives 14.719
   from the same fonts, and the section below the header (which pulls itself up
   with `margin-top:-70px` and is NOT ours to touch) lands where it always did.

   Lose any of it and the whole page moves 26 or 70px, on all 11 routes.
   ============================================================ */
.serena-header {
	display: inline-flex;
	vertical-align: middle;
	align-items: center;
	/*
	 * `sticky`, not `relative` and not `fixed` — this is the whole desktop
	 * sticky, in one declaration and no JavaScript (#26).
	 *
	 * `fixed` is ruled out by measurement, not by taste. The control pins with
	 * `position:fixed` and pays for the hole it leaves in the flow with a CLONE:
	 * at scroll 360 there are two `.sticky-header` elements, one `fixed` at
	 * top:0 and one `relative` left behind. This markup renders the bar ONCE, so
	 * taking it out of the flow would delete the 26px line box the whole
	 * document is measured against and pull every desktop page UP by 26px — the
	 * +1545px bug's twin with the sign flipped.
	 *
	 * `sticky` keeps the element in flow, so the line box survives, and pins it
	 * at top:0 on scroll. Three conditions checked before writing this:
	 * `.serena-header` is a direct child of <body>; `html` is `overflow:visible`;
	 * and body's `overflow: hidden scroll` therefore PROPAGATES to the viewport,
	 * so body is not a scroll container and cannot clip the sticky.
	 *
	 * At rest it paints exactly where `relative` painted it (top 14.72 at 1280,
	 * measured on the control), because a sticky box's unstuck position is its
	 * flow position. It is still a positioned element, so it remains the
	 * containing block for the absolutely-positioned panels of section 5.
	 *
	 * The <=1024 block below already declared `sticky; top:0` for the mobile
	 * bar; stating it here makes it one declaration site for both breakpoints
	 * instead of two, and changes nothing on mobile.
	 */
	position: sticky;
	top: 0;
	width: 100%;
	max-width: 100%;
	height: var(--sc-bar-h);
	/* Margin box height 0 => contributes only body's 26px line box. */
	margin-bottom: calc(-1 * var(--sc-bar-h));
	/* Elementor's header root sat at 110; the page below it has none, so the
	   bar paints over the hero exactly as it does today. */
	z-index: 110;
	box-sizing: border-box;
}

/* ============================================================
   2. Logo
   ============================================================ */
.serena-header__logo {
	/*
	 * 5 + the image's height + 5 sits in `--sc-bar-h`, and
	 * centred by the bar's `align-items: center`, which splits the remainder.
	 *
	 * The comment here used to spell that out as "the 65.5px bar" — a literal
	 * that this file no longer contains anywhere, since `--sc-bar-h` became an
	 * expression. A comment that restates a value instead of naming the token
	 * goes stale silently the first time the token moves, and then reads as
	 * documentation while being wrong. Named, not restated.
	 *
	 * The 5px are still literals and still un-tokenised, deliberately: they are
	 * the logo's own inset inside the bar, nothing computes from them, and the
	 * image's height is no longer a fixed 50 for them to be bound to.
	 */
	margin: 5px 0 5px 20px;

	/*
	 * The width is a PERCENTAGE, because that is what the control declares.
	 *
	 * Read out of the control with CSSOM rather than inferred from its outputs:
	 *
	 *   post-5993.css  @media (min-width: 768px)
	 *     .elementor-5993 .elementor-element-b0d82a0 { --width: 15.225% }
	 *     @media (max-width:1024px) and (min-width:768px) { --width: 25% }
	 *     @media (max-width:767px)                        { --width: 30% }
	 *   custom-frontend.min.css   .e-con { width: var(--width) }
	 *
	 * and the logo image itself carries NO width rule at all on the control —
	 * only Bridge's `img { max-width: 100%; height: auto }`. So the size is
	 * "the asset's intrinsic width, capped by a percentage container", and the
	 * 180px cap that the old `width: 180px` hard-coded is simply the asset.
	 *
	 * A fitted formula was available and is rejected on evidence. Eight samples
	 * fit `0.152514 * vw - 6.296` to within 0.01px and predict the cap at 1221.5,
	 * which the dense sweep confirms. It would have passed the gate at both
	 * measured widths and been wrong in kind: the control's container is
	 * `flex: 0 1 auto` and its used width is an emergent property of the flex
	 * line it shares with the nav — so it depends on THE MENU'S CONTENT, and the
	 * formula would have broken silently the day somebody renamed an item.
	 * Percentages do not have that failure mode.
	 */
	flex: 0 1 auto;
	width: 15.225%;
}

.serena-header__logo a {
	display: inline-block;
}

/*
 * `vertical-align:middle` is load-bearing, not cosmetic.
 *
 * The logo is an atomic inline inside a line box whose strut is 16px/26px. With
 * `middle`, the image's centre aligns half an x-height above the baseline, and
 * that is what makes the wrapper exactly 50px tall at 1280 (the image wins the
 * line box outright) and exactly 28.1875px tall at 390 (the image is shorter
 * than the strut's ascent, so the strut wins the top and the image the bottom,
 * leaving the 1.25px gap the control has). Switch this to `top`/`baseline` or
 * make the image `display:block` and the mobile bar loses 1.25px of height —
 * which pushes every mobile page up by 1.25px and reddens all 11 mobile cells.
 */
.serena-header__logo img {
	display: inline-block;
	vertical-align: middle;
	/*
	 * No `width`. The asset is 180x50 and it is capped by the percentage wrapper
	 * above — which is exactly how the control does it, and why the 180 never
	 * appears as a number here. `width: 180px; height: 50px` used to be
	 * declared, and it froze the logo at its capped size across the whole
	 * 1025-1240 ramp (issue #41).
	 */
	max-width: 100%;
	height: auto;
}

/* ============================================================
   3. Navigation: the horizontal bar of top-level items
   ============================================================ */
/*
 * The nav carries the SECOND HALF of the logo's size, and that is not a figure
 * of speech — it is why the logo rule alone could not land.
 *
 * The control declares both columns as percentages that do NOT sum to 100:
 *
 *   post-5993.css  @media (min-width: 768px)
 *     .elementor-element-b0d82a0 (logo) { --width: 15.225% }
 *     .elementor-element-98ee9dc (nav)  { --width: 84.653% }   <- read, not solved for
 *   plus --margin-left: 20px on the logo and --margin-right: 20px on the nav.
 *
 * 15.225 + 84.653 = 99.878%, and then 40px of margins on top. The line is
 * declared to OVERFLOW by design, and since neither column may grow
 * (`--flex-grow: 0`) while both may shrink, flexbox takes that overflow back out
 * of them in proportion. That is where the control's logo gets its width: not
 * from its own percentage, but from its percentage minus its share of a
 * deliberate overflow.
 *
 * Ours could not reproduce it while this rule said `flex: 1 1 auto`. A GROWING
 * sibling absorbs the 40px instead of sharing the shrink, so the logo sat at its
 * full 15.225% — 6px too wide at every width on the ramp. The logo rule was
 * correct and still measured wrong, because half the mechanism was here.
 *
 * `box-sizing: border-box` is load-bearing too. The control's containers are
 * border-box; ours was content-box, so `84.653%` meant that PLUS 20px of
 * padding, the line overflowed by 20px more than the control's, and the logo
 * over-shrank by 2.94px — right mechanism, wrong box model, and the error
 * changed sign instead of disappearing. Which is worth remembering: an error
 * that reverses under a fix is evidence the fix is close, not evidence it is
 * wrong.
 *
 * Verified against the control at four widths — logo image and both columns:
 *
 *   vw     logo img         logo column        nav column
 *   1025   150.031x41.672   20 / 150.031       170.031 / 834.969
 *   1100   161.469x44.844   20 / 161.469       181.469 / 898.531
 *   1280   180x50           20 / 188.922       208.922 / 1051.078
 *   1600   180x50           40 / 231.547       271.547 / 1288.453
 *
 * identical on both trees, to the thousandth, at all four.
 */
.serena-header__nav {
	flex: 0 1 auto;
	width: 84.653%;
	box-sizing: border-box;
	min-width: 0;
	display: flex;
	flex-direction: column;
	/* 10px all round + 20px on the right is what puts the last item's right
	   edge at x=1250 and the items' baseline at y=24.719. Tokenised because the
	   panels' `top` is derived from this same padding. */
	padding: var(--sc-nav-pad);
	margin-right: 20px;
}

/*
 * Above 1366 the control doubles both outer margins. Read off post-5993.css,
 * where 40px is the base value and `@media (max-width: 1366px)` overrides it to
 * 20 — written here as the exception rather than the base, because the 20px
 * above already sit unconditionally and the cascade needs it this way round.
 *
 * Outside the matrix, which samples 1280 and 1100. At 1600 the logo sat 20px too
 * far left without this and nothing would ever have reported it.
 */
@media (min-width: 1367px) {
	/*
	 * Above 1366 the bar stops being a zero-height inline and becomes a normal
	 * block in the flow. This is a LAYOUT MODE change, not a tweak.
	 *
	 * Measured on the control, home page, at rest:
	 *
	 *   vw <= 1366   header root  y = 14.719   h = 0      (the atomic inline)
	 *   vw >= 1367   header root  y =  0       h = 65.5   (a block in flow)
	 *
	 * and the section below it, which pulls itself up with `margin-top: -70px`:
	 *
	 *   vw <= 1366   starts at -44     (26px line box - 70)
	 *   vw >= 1367   starts at  -4.5   (65.5 - 70)
	 *
	 * 65.5 - 26 = 39.5, which is exactly the amount by which the whole document
	 * was short above 1366: 6605 against the control's 6644 at 1600, 6551 against
	 * 6590 at 1440, 6526 against 6565 at 1367. Every page, every route.
	 *
	 * ⚠ HOW THIS WAS MISSED, because it is the fourth instance of one shape.
	 *
	 * The margins below were verified at 1600 by DOM probe and agreed with the
	 * control to the thousandth: logo column x=40 w=231.547, nav x=271.547
	 * w=1288.453, the `Áreas` label at x=818. That verification was not wrong. It
	 * measured X, and the defect was in HEIGHT — so the probe returned "identical"
	 * about a header that pushed every page 39.5px up.
	 *
	 * The same shape had already happened three times in this issue: the panel's
	 * height matched for five rounds while its `top` was 10px out; `width: 12%`
	 * was rejected by measuring outputs that were wrong for an unrelated reason;
	 * and #39's mechanism was deduced correctly and then dismissed as
	 * unbuildable without being tried. A PROBE IS ONLY AS GOOD AS THE PROPERTY IT
	 * OCCURRED TO YOU TO ASK ABOUT — and "verified at four widths" says nothing
	 * about the axis you did not sample.
	 *
	 * Caught by adding the 1600 column to the matrix, which is what a capture
	 * does that a probe does not: it compares every pixel, including the ones no
	 * question was asked about.
	 */
	.serena-header {
		display: flex;
		margin-bottom: 0;
	}

	.serena-header__logo {
		margin-left: 40px;
	}

	.serena-header__nav {
		margin-right: 40px;
	}
}

.serena-header__items {
	display: flex;
	justify-content: flex-end;
	flex-wrap: wrap;
	/* `.clean-list` gets its reset from the compiled style.css; this list has
	   no such friend, so it resets itself. */
	list-style: none;
	margin: 0;
	padding: 0;
}

.serena-header__item {
	display: flex;
}

/*
 * One rule for both trigger shapes. A plain link renders as `<a>`, a panel
 * trigger as `<button>` — semantically right, visually identical, which means
 * the button needs its entire user-agent skin removed rather than tweaked.
 */
.serena-header__title {
	display: flex;
	align-items: center;
	/* Vertical half tokenised: `--sc-bar-h` is computed from it. The 15px
	   horizontal is this rule's own business and nothing depends on it. */
	padding: var(--sc-title-pad-y) 15px;
	margin: 0;
	border: 0;
	background: none;
	-webkit-appearance: none;
	appearance: none;
	font-family: Nunito, sans-serif;
	font-size: 16px;
	font-weight: 700;
	line-height: 26px;
	color: var(--sc-ink);
	text-align: start;
	text-decoration: none;
	white-space: nowrap;
	cursor: pointer;
}

.serena-header__title:hover,
.serena-header__title:focus {
	text-decoration: none;
}

.serena-header__title-text {
	display: flex;
	align-items: center;
	position: relative;
	font-family: Nunito, sans-serif;
	font-size: 17px;
	font-weight: 700;
	/* Tokenised: this is the middle term of `--sc-bar-h`, and through it the
	   `top` of all three mega-menu panels. */
	line-height: var(--sc-title-lh);
	color: var(--sc-ink);
	white-space: nowrap;
	transition: color 0.2s ease;
}

/* The animated underline, ported from header-modern.css. Invisible at rest
   (left and right both at 50%), so it costs the pixel gate nothing — and the
   gate never captures :hover, so this is unverified by it either way. */
.serena-header__title-text::after {
	content: "";
	position: absolute;
	left: 50%;
	right: 50%;
	bottom: -8px;
	height: 2px;
	background: var(--sc-coral);
	border-radius: 2px;
	transition: left 0.25s ease, right 0.25s ease;
}

.serena-header__item:hover .serena-header__title-text {
	color: var(--sc-coral);
}

.serena-header__item:hover .serena-header__title-text::after {
	left: 0;
	right: 0;
}

/*
 * The caret.
 *
 * The control paints a Font Awesome `angle-down` as an inline <svg>; the native
 * markup has no element for it, and `inc/serena-header.php` is out of bounds for
 * this issue, so it is drawn as a background on `::after`. Same path, same
 * viewBox, same 17x17 box, same #4F4F4F — and `background-size:contain` rather
 * than `17px 17px` because an SVG with a 320x512 viewBox and no width/height is
 * fitted with `xMidYMid meet` when it is inline, and only `contain` reproduces
 * that; `17px 17px` would stretch it to a square.
 */
.serena-header__panel-toggle::after {
	content: "";
	flex: 0 0 auto;
	width: 17px;
	height: 17px;
	margin-left: 5px;
	background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 320 512'%3E%3Cpath fill='%234F4F4F' d='M143 352.3L7 216.3c-9.4-9.4-9.4-24.6 0-33.9l22.6-22.6c9.4-9.4 24.6-9.4 33.9 0l96.4 96.4 96.4-96.4c9.4-9.4 24.6-9.4 33.9 0l22.6 22.6c9.4 9.4 9.4 24.6 0 33.9l-136 136c-9.2 9.4-24.4 9.4-33.8 0z'/%3E%3C/svg%3E");
	background-position: center;
	background-size: contain;
	background-repeat: no-repeat;
	transition: transform 0.25s ease;
}

/*
 * Open: the control swaps the glyph for `angle-up` — AND changes its colour.
 *
 * The fill here is #1F2124, not the #4F4F4F of the closed state, and that is
 * read off the control rather than inferred: with a panel open its caret is
 *
 *   <svg class="e-font-icon-svg e-fas-angle-up" viewBox="0 0 320 512">
 *   computed fill: rgb(31, 33, 36)   box 17x17 at x=569
 *
 * while the closed one is #4F4F4F, which is why the closed caret has always
 * measured 0 AE and only the open one was off. The symptom was small and easy
 * to file under "antialiasing": ~48 AE on a 10x7 region, with the control
 * consistently DARKER (B5B5B6 against C5C5C5). It is 32 units of ink, not a
 * rasterisation artefact — and it was on all nine panel cells because every
 * open panel has exactly one open caret.
 *
 * Two wrong turns are worth recording. Rotating the closed glyph instead of
 * swapping it left the caret at 48 AE (so the shape was never the issue) and
 * cost 12 000 AE elsewhere, because a `transform` on the pseudo-element
 * promotes it and takes the whole bar's subpixel antialiasing with it. And the
 * darkness was nearly written off as a rasterisation difference between an
 * inline <svg> and a background image — the closed caret, identical in
 * mechanism and exact in pixels, is what ruled that out.
 */
.serena-header__panel-toggle[aria-expanded="true"]::after {
	background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 320 512'%3E%3Cpath fill='%231F2124' d='M177 159.7l136 136c9.4 9.4 9.4 24.6 0 33.9l-22.6 22.6c-9.4 9.4-24.6 9.4-33.9 0L160 255.9l-96.4 96.4c-9.4 9.4-24.6 9.4-33.9 0L7 329.7c-9.4-9.4-9.4-24.6 0-33.9l136-136c9.4-9.5 24.6-9.5 34-.1z'/%3E%3C/svg%3E");
}

/* ============================================================
   4. The drawer toggle (mobile only; 0x0 at 1280, as measured)
   ============================================================ */
.serena-header__toggle {
	display: none;
}

/* ============================================================
   5. The panels — CLOSED, and out of the flow

   `display:none` is what removes the +1545px / +1394px: with no CSS at all the
   three panels rendered expanded, stacked, inside the bar. `position:absolute`
   is what keeps them out of the flow once #26 opens them — an open panel that
   is still in flow would push the page down by its own height and turn every
   route red the moment a panel is used.

   The containing block is `.serena-header` (the only positioned ancestor: the
   `<li>` is deliberately left static), so `left:0; right:0` gives the panel the
   full-bleed 0..1280 span the control's `.e-n-menu-content` gets from its
   `left:-218.922px; right:-30px`.

   No JavaScript here by design — #26 owns opening. Two signals are accepted so
   that #26 can pick either: the trigger's own `aria-expanded` via `:has()`, and
   an `is-open` class for browsers or code paths where `:has()` is not enough.
   The OPEN geometry below is a starting point, not a measurement: the control's
   open panels could not be captured (Elementor's own JS drives them), so #26
   validates it against `home__desktop__panel-*` and adjusts.
   ============================================================ */
.serena-header__panel {
	display: none;
	position: absolute;
	left: 0;
	right: 0;
	/*
	 * The panel hangs off the nav's CONTENT-box bottom, not off the bar.
	 *
	 * Measured on the control, at 1280:
	 *
	 *   nav.e-n-menu          top 24.719  height 45.5  bottom 70.219
	 *   .e-n-menu-content     top: 45.5px, and its containing block IS that nav
	 *
	 * so the control's panel starts exactly where the nav's box ends. Ours hung
	 * off `100%` of `.serena-header`, which is `--sc-bar-h` = 65.5, and 65.5 is
	 * the nav's box PLUS its 10px of padding — hence the +10px that put every
	 * label, the coral border and the shadow one notch low on all nine panel
	 * cells.
	 *
	 * Written as a subtraction of the token rather than as `55.5px` on purpose.
	 * `--sc-bar-h` is defined as `45.5 + 2 * --sc-nav-pad`, so taking one
	 * padding back off the bottom is the nav's content-box bottom BY
	 * CONSTRUCTION, at any width and whatever those two values become. A literal
	 * would be the `calc(100% - 3.094px)` mistake of #38 with a different
	 * number: correct at the width it was fitted to and silently wrong
	 * elsewhere.
	 *
	 * Check against the control: 65.5 - 10 = 55.5, and 14.719 + 55.5 = 70.219,
	 * which is the nav's measured bottom to the thousandth.
	 */
	top: calc(100% - var(--sc-nav-pad));
	z-index: 2147483620;
	flex-direction: row;
	/*
	 * The control's `e-con-inner` lays its columns out with `justify-content:
	 * normal` and `gap: 0` — the columns fill the row because each one is half
	 * of it (see `.serena-header__column`). `center` + `gap: 60px` was #25's
	 * unmeasured starting point and it shrink-wrapped both columns, which is
	 * what pushed the whole of `Áreas` 328px to the right.
	 */
	justify-content: flex-start;
	gap: 0;
	/*
	 * Side inset derived from the content width, so the panel is boxed and
	 * centred exactly as the control is at every viewport — and collapses to 0
	 * below 1180px instead of holding a 50px gutter the control does not have.
	 * At 1280 this evaluates to 50px, which is why the fitted form measured
	 * identical here and only here.
	 *
	 * The `32px` and `36px` are #25's, carried over unchanged, and they are the
	 * one pair in this declaration that was never questioned — so they were
	 * probed the same way: the control's `e-con-inner` reports `padding-top:
	 * 32px; padding-bottom: 36px` at BOTH 1280 and 1600, unlike its horizontal
	 * inset, which moves from 50 to 210 across the same pair. Vertical absolute,
	 * horizontal derived. Asymmetric, and now measured rather than assumed.
	 */
	padding: 32px max(0px, (100% - var(--sc-panel-content-w)) / 2) 36px;
	background: #fff;
	box-sizing: border-box;
}

/*
 * `Recursos` is a COLUMN of links, not a row of columns.
 *
 * ⚠ Scoped to this one panel. `Áreas` and `Entrar` are rows and measure exactly
 * against the control; widening this to the shared rule would break two panels
 * that are already right.
 *
 * Measured on the control:
 *
 *   .e-con-inner     flex-direction: column   gap: 15px   -> 6 links stacked,
 *                                                            content 247px
 *   ours (before)    flex-direction: row      gap: 60px   -> 6 side by side,
 *                                                            content  28px
 *
 * That is the whole -219: 32 + 36 + 28 + 3 = 99 against 32 + 36 + 247 + 3 = 318.
 *
 * And the gap is 15px here, not the 60px the row panels use. This is the fifth
 * place in this issue where the control reaches its result by a different route
 * per panel — icon width, icon margin, column spacing, link chrome, and now
 * layout direction. The rule for the rest of F3 stands: a uniform-looking
 * difference does not imply a uniform cause.
 */
.serena-header__panel.submenu-recursos {
	flex-direction: column;
	gap: 15px;
	/*
	 * The six links are CENTRED, and in a column flexbox that is `align-items`
	 * (the cross axis), not `justify-content`.
	 *
	 * This is the whole of the horizontal half of the `Recursos` difference, and
	 * it is scoped here because the control does it here: its `e-con-inner`
	 * carries `align-items: center` in this panel and `normal` in the other two.
	 *
	 * Measured, control vs native before the fix — same widths, different x:
	 *
	 *   HAZ NUESTROS testS   w 181   ctrl x 549.5   native x 50
	 *   Guías gratuitas      w 150   ctrl x 565     native x 50
	 *   Blog                 w  62   ctrl x 609     native x 50
	 *
	 * Every control x is `50 + (1180 - w) / 2`, i.e. centred in the content box,
	 * while ours stretched to the full 1180 and left the text at the padding
	 * edge. Identical widths on both sides is what says the difference is
	 * alignment and nothing else.
	 */
	align-items: center;
}

.serena-header__item--has-panel:has(> .serena-header__panel-toggle[aria-expanded="true"]) > .serena-header__panel,
.serena-header__item--has-panel.is-open > .serena-header__panel,
.serena-header__panel.is-open {
	display: flex;
}

@media (min-width: 1025px) {
	.serena-header__item--has-panel:has(> .serena-header__panel-toggle[aria-expanded="true"]) > .serena-header__panel,
	.serena-header__item--has-panel.is-open > .serena-header__panel,
	.serena-header__panel.is-open {
		box-shadow: 0 24px 48px -20px rgba(177, 25, 114, 0.22);
		border-top: 3px solid var(--sc-coral);
		border-radius: 0 0 20px 20px;
	}

	/*
	 * The panel's inner box: opaque, and SQUARE. It is what the control's
	 * `.e-con` is, rebuilt as a pseudo-element because the markup has no such
	 * wrapper and `inc/serena-header.php` is not this issue's to change.
	 *
	 * It does two jobs, and both are measured.
	 *
	 * With a panel open, all six triggers are identical in the DOM: same box,
	 * same colour, same letter-spacing, same `::after` underline, on all three
	 * panels. Yet the bar row differed by ~3760 AE and the panel's own text by
	 * ~668 AE per line. Reading the pixels named it:
	 *
	 *   control  EEC891  75B2E3  D3A175   <- R != G != B, LCD/subpixel AA
	 *   native   CFCFCF  B5B5B5  AAAAAA   <- R  = G  = B, grayscale AA
	 *
	 * Chrome will not use LCD text where it cannot prove the backdrop is opaque,
	 * and an open panel's shadow is what takes that proof away. `.serena-header`
	 * is transparent by design (the pink band behind it belongs to the page), so
	 * every label in the bar changed rasterisation without moving a pixel —
	 * including the five not involved in the interaction at all.
	 *
	 * Removing the shadow is not on the table: the control declares exactly this
	 * shadow. What the control ALSO does, and we did not, is keep the shadow and
	 * the text on DIFFERENT boxes — `.e-n-menu-content` carries the shadow and is
	 * `background-color: rgba(0,0,0,0)`, while the `.e-con` inside it paints the
	 * white and holds every glyph. This pseudo-element restores that split: the
	 * panel keeps the shadow, the pseudo paints the opaque white the glyphs are
	 * rasterised against.
	 *
	 * Bisected by injecting one override at a time and measuring TWO windows
	 * against the control — the bar row and one line of panel text:
	 *
	 *   (unfixed)                         nav 3760   text  668
	 *   will-change / translateZ / …      nav   48   text  668
	 *   isolation: isolate                nav 3760   text  668
	 *   z-index 2 / auto                  nav 3760   text  668
	 *   position: relative on the bar     nav 3760   text  668
	 *   background:#fff on the bar        nav 3760   text  668
	 *   box-shadow: none                  nav   48   text    0
	 *   this pseudo                       nav   48   text    0
	 *
	 * Two of those rows earn their place. `isolation: isolate` failing while
	 * every layer promotion succeeds separates "stacking context" from
	 * "compositing layer". And promotion fixed the bar while leaving the panel's
	 * own text wrong — a fix that moves a defect from the window you are looking
	 * at into the one you are not is indistinguishable from a fix if you only
	 * measure one window. Both windows were measured for every candidate.
	 *
	 * Two candidates got as far as being written into this file before being
	 * withdrawn. `will-change: transform`, which fixed the bar and left the panel
	 * text wrong. And opaque backgrounds on the columns, which scored 365 on
	 * `Áreas` because those columns happen to cover the panel — `Recursos`, whose
	 * children shrink-wrap once they are centred, got WORSE (3917 -> 7570). Every
	 * candidate is measured on all three panels now.
	 *
	 * ---- and `border-radius: 0` is the second job, also measured ----
	 *
	 * Square, deliberately, even though the panel above it is rounded. The
	 * control's bottom corners are declared `0 0 20px 20px` and are NOT VISIBLE:
	 * its opaque square `.e-con` covers the cut-out the radius would leave. Read
	 * off the control at the bottom-left corner, panel bottom 572.719:
	 *
	 *   y=570,571,572  x=0..7   FFFFFF  <- white to the very edge: square
	 *   y=573          x=0..7   FCF8FB  <- the shadow, immediately below
	 *
	 * So the radius is a declaration with no pixels behind it, and rounding this
	 * box instead would expose the shadow in the corner — which is exactly what
	 * the rounded version measured: 352 / 234 / 565 against 167 / 48 / 379.
	 *
	 * ⚠ Worth stating plainly, because it is the kind of thing that reads as a
	 * fluke: this is NOT "square happens to score better". The control was
	 * measured first and found to be square in the pixels; the rule follows the
	 * measurement. Had the page behind the corner not been white, rounded and
	 * square would still differ — and the control would still be square.
	 */
	.serena-header__panel::before {
		content: "";
		position: absolute;
		inset: 0;
		z-index: -1;
		background: #fff;
		border-radius: 0;
	}

	/*
	 * ...and the panel itself goes transparent, so that the split described
	 * above is a real split and not an opaque box stacked on an opaque box.
	 *
	 * Measured: with the pseudo in place, `background: transparent` here scores
	 * 0 / 0 / 331 — identical to shipping the white — because the pseudo covers
	 * the panel everywhere the white was ever visible. Turning off the PSEUDO's
	 * background instead scores 14 832 / 7 522 / 5 619. That pair is what says
	 * which of the two boxes is load-bearing, and it is not this one.
	 *
	 * So this declaration changes no pixels and is here for the failure mode.
	 * With both boxes white, deleting the pseudo leaves a panel that still looks
	 * entirely correct while having silently lost subpixel antialiasing on every
	 * label in the bar — the exact defect this issue spent its length chasing,
	 * reintroduced invisibly. With the panel transparent, deleting the pseudo
	 * gives a panel with no background at all: loud, immediate, impossible to
	 * ship by accident. A dependency that announces itself when broken is worth
	 * a declaration that paints nothing.
	 *
	 * NOT applied below 1025px: there the panel is an accordion body inside the
	 * drawer, the pseudo does not exist, and this white is the only white there
	 * is.
	 */
	.serena-header__panel {
		background: transparent;
	}
}

/*
 * Each column is HALF the panel's content box — proportional, and measured to be
 * proportional rather than assumed.
 *
 * At 1280 the control's columns are 590px wide, which is both "half of 1180" and
 * "590px". The matrix has one desktop width and cannot separate those, so the
 * control was measured at a second one:
 *
 *   content 1180 (vw 1280/1440/1600) -> columns 590 / 590
 *   content 1100 (vw 1100)           -> columns 550 / 550
 *
 * The columns track the content box, so 50% is the mechanism and `590px` would
 * have been a constant fitted to the only width the gate looks at.
 */
.serena-header__column {
	flex: 0 0 50%;
	/*
	 * `border-box`, because 50% has to mean 50% of the row INCLUDING the padding
	 * the `Entrar` columns carry. Under the default `content-box` the second
	 * column started 20px late (its sibling's 10px of left and right padding
	 * added to the 590), which put every icon and title in the right-hand column
	 * 20px off while the left-hand one looked correct — the kind of asymmetry
	 * that reads as "the second column is broken" instead of "the box model is".
	 */
	box-sizing: border-box;
}


/*
 * The 20px between a column's heading and its list.
 *
 * ⚠ TWO DIFFERENT MECHANISMS ON PURPOSE. Do not unify them.
 *
 * The control produces the same 20px by different means in each panel, and it
 * was measured node by node:
 *
 *   .submenu-areas    column is `display:flex` with `gap: 20px`
 *                     (51.50 heading + 20 gap + 360 list = 431.50)
 *   .submenu-acceder  column carries `padding: 10px`, i.e. 10 top + 10 bottom
 *                     (68.92 heading + 20 padding = 88.92)
 *
 * A single rule reproduces one of them and breaks the other: a gap needs a
 * second child to apply between, and `Entrar`'s column has only the heading —
 * a `gap` there would render exactly nothing, and the deficit would survive
 * looking fixed.
 *
 * This is the third time in this issue that the current site reaches the same
 * visual result by different routes per panel (icon width, icon margin, and now
 * this). The general rule for the rest of F3: A UNIFORM DIFFERENCE DOES NOT
 * IMPLY A UNIFORM CAUSE — measure per panel before writing one rule for all.
 */
.serena-header__panel.submenu-areas .serena-header__column {
	display: flex;
	flex-direction: column;
	gap: 20px;
}

.serena-header__panel.submenu-acceder .serena-header__column {
	/*
	 * All four sides now, as the control declares it.
	 *
	 * This used to be `10px 0` with a note saying the horizontal half was being
	 * withheld because the panels' horizontal geometry was #25's unmeasured
	 * starting point, and mixing a measured fix with an unmeasured one would
	 * make neither checkable. It IS measured now — the columns are half the
	 * content box — so the note has been honoured rather than deleted:
	 *
	 *   control  column x 50, width 590, padding 10  -> icon anchor at x 60,
	 *            icon at 72 (the anchor's own 12px of padding)
	 *
	 * which is the x the control measures. The withheld half goes in with the
	 * geometry it depended on.
	 */
	padding: 10px;
}

/* ============================================================
   Panel internals: the chrome EVERY anchor in a panel wears

   Ported from the rule that does this in the control:

     .elementor-location-header .e-n-menu-content a:not(.elementor-image-box-img)
       { padding: 7px 12px; display: inline-block; }
     -- wp-content/themes/bridge-child/header-modern.css

   Enumerated across `document.styleSheets`, not assumed: it is the ONE rule
   that matches all three kinds of anchor in a panel — the image link, the
   heading link and the list links — in both `Áreas` and `Entrar`.

   ## Why it was missing, and what it cost

   ADR §3.5 said `header-modern.css` would be re-scoped off
   `.elementor-location-header` in this phase. It was not: #25 wrote a new file
   instead and ported only ONE of the three anchors (`.clean-list a`). With the
   flag ON, `.elementor-location-header` does not exist, so every declaration in
   that file applies to nothing — and the two anchors it did not port went
   missing without a trace.

   That single omission is BOTH residues we spent three rounds chasing:

     - the icon's 21px of link chrome (24 horizontal, 14 vertical) plus 7px of
       inline-block baseline descent: 30.50 img + 14 + 7 = 51.50 in Áreas,
       47.92 + 14 + 7 = 68.92 in Entrar — the control's figures, exactly.
     - the heading text block: ours 26.80 against the control's 40.80, and
       26.80 + 14 = 40.80.

   It rendered nothing on the flag-off path, which is why it read as harmless.
   ⚠ A difference that paints nothing TODAY is not a harmless difference. It is
   one that has not been measured yet.

   ## Declared here rather than by re-scoping header-modern.css

   That file is what styles the FLAG-OFF path — what production serves today and
   what a rollback returns to. Re-scoping it would merge the two paths back
   together right after the conditional enqueue separated them. This file owns
   the flag-on path; the duplication is two declarations.

   ## The `:not()` is deliberately NOT ported

   In the control `.elementor-image-box-img` is the class of the <figure>, never
   of the <a>, so that `:not()` excludes nothing — every anchor gets the padding,
   including the image's. Carrying the selector over verbatim would look faithful
   while risking the opposite: in this markup the class also sits on the <figure>
   today, but a future refactor that moved it onto the link would silently switch
   the image anchor off and bring causa 2 back.
   ============================================================ */
.serena-header__panel a {
	display: inline-block;
	padding: 7px 12px;
}

/* ---- Panel internals: the image-box heading of a column ---- */
.serena-header__panel .elementor-image-box-wrapper {
	display: flex;
	align-items: flex-end;
}

/*
 * The icon is sized by the CONTROL'S OWN MECHANISM, per panel — and the two
 * panels do not share one.
 *
 *   .submenu-areas    post-5993.css declares `.elementor-image-box-img { width: 12% }`
 *   .submenu-acceder  declares NO desktop width at all (only `45px` below 767)
 *
 * so `Áreas` is a percentage of its column and `Entrar` is shrink-to-fit around
 * its image. Both figures are `flex: 0 1 auto`, and their sibling
 * `.elementor-image-box-content` is `width: 100%`, so each wrapper is declared
 * to OVERFLOW and the two children give the overflow back in proportion. Same
 * shape as the header row one level up, where the logo and the nav sum to
 * 99.878% and then shrink.
 *
 * ⚠ WHAT THIS REPLACES, and why the previous reasoning was sound and still wrong.
 *
 * This block used to hold `63.22px` and `71.92px` — the control measured at 1280
 * and frozen — under a comment that recorded `width: 12%` as having been TRIED
 * AND REJECTED, for two measured reasons:
 *
 *   1. "The control uses a different absolute width per panel, and one
 *      percentage yields one ratio, never two."
 *   2. "Within a panel the columns are not equally wide (552 vs 513 in Áreas),
 *      so a percentage of the column produced two different icon sizes where the
 *      control has two identical ones."
 *
 * Both observations were correct. Both have since dissolved:
 *
 *   (2) went first, and not on purpose. The 552-vs-513 asymmetry was never a
 *       property of the control — it was OUR columns shrink-wrapping, because
 *       the panel was laying them out with `justify-content: center` and a 60px
 *       gap. #26 replaced that with the control's own `50%` columns, which are
 *       550/550 at 1100 and 590/590 at 1280. The obstacle to the percentage was
 *       a defect somewhere else, and fixing that defect removed it.
 *   (1) went when the two panels' rules were actually read instead of inferred
 *       from their outputs. They do not need one percentage to yield two ratios,
 *       because the control does not use one percentage: it uses a percentage in
 *       one panel and shrink-to-fit in the other.
 *
 * The lesson is not that the earlier reading was careless — it measured real
 * numbers and drew a defensible conclusion. It is that BOTH reasons were about
 * outputs, and outputs are downstream of every other defect in the layout. A
 * mechanism ruled out by measuring results stays ruled out only while the rest
 * of the results are right.
 *
 * And `flex-shrink: 0` is the same story in miniature. It was added because
 * "12% of a 552px column is 66.24px and it measured 59.14px — a width that the
 * layout is free to ignore is not a width". But that squeeze WAS the control's
 * mechanism, observed and mistaken for a bug: the control's figure is also
 * squeezed, from 66 to 58.922 at 1100. Suppressing it and pasting the result
 * back as a literal reproduced the number at one width and the mechanism at
 * none.
 *
 * Verified against the control at both matrix widths, all four figures:
 *
 *            vw 1100                vw 1280
 *   Áreas    34.906 x 27.156        39.203 x 30.500
 *   Entrar   47.141 x 47.141        47.922 x 47.922
 *
 * exact on every one.
 */
.serena-header__panel .elementor-image-box-img {
	/* Shrinkable, because the shrink IS the mechanism — see above. */
	flex: 0 1 auto;
	margin: 0;
}

.serena-header__panel .elementor-image-box-img img {
	display: block;
	/*
	 * `width: auto; max-width: 100%` — the control's literal form, and the only
	 * one of four that lands on its exact pixel.
	 *
	 * This used to read `width: 100%`, with a comment arguing that max-width
	 * "only caps, so an asset narrower than the box would keep its natural size".
	 * True, and beside the point: the figure is a PERCENTAGE of the column now,
	 * so the box is always narrower than the asset and the cap is what does the
	 * sizing. The old reasoning was sound about a layout that no longer exists.
	 *
	 * The difference between the two is one LAYOUT UNIT, and it is not cosmetic:
	 *
	 *   width: 100%              vw 1100 -> 34.922   vw 1280 -> 39.219
	 *   width:auto + max-width   vw 1100 -> 34.906   vw 1280 -> 39.203
	 *   control                  vw 1100 -> 34.906   vw 1280 -> 39.203
	 *
	 * 1/64px, and it moves every antialiased edge of the icon. It is what the
	 * 119 AE at 1280 was, and what the 20 AE left over at 1100 under a masked
	 * diagnostic was — that residual was recorded as "not established" precisely
	 * because a mask built from 3-decimal values could not resolve it. With the
	 * mechanism in place instead of the mask, it resolves: same cause, both
	 * widths, closed.
	 */
	width: auto;
	max-width: 100%;
	height: auto;
}

/*
 * The image's link takes its width FROM THE FIGURE, never from the image.
 *
 * Without this the box sizes itself backwards. The anchor is `inline-block` (the
 * panel's link chrome), so with no width of its own its width is shrink-to-fit —
 * and while that is being computed, the `width: 100%` on the <img> above counts
 * as `auto`, so the image contributes its INTRINSIC width. The anchor sizes
 * itself from the image and the image then fills the anchor: the figure's
 * carefully measured width governs nothing.
 *
 * Measured with the anchor left to shrink-to-fit:
 *
 *   Áreas    both columns   a =  63.22 = the figure    -> right
 *   Entrar   column 1       a =  71.91 = the figure    -> right
 *   Entrar   column 2       a = 127.00, img 103x103    -> OVERFLOWS by 55.09,
 *                           wrapper 117 instead of 68.92, panel +48.08
 *
 * ⚠ Three of those four were right BY CLAMP, not by construction: their images
 * are wide enough that shrink-to-fit hits the available width and stops there.
 * The one that misbehaves is the only column served as `attachment-60x60`
 * instead of `attachment-full`. The Áreas panel measured 502.50 against the
 * control's 502.50 while resting on that accident — an unexplained correct
 * number is a regression waiting for its turn, and the way to tell the two apart
 * is to go and find out WHY the right answer is right.
 *
 * An explicit width removes shrink-to-fit entirely, and `border-box` takes the
 * 24px of horizontal padding OUT of the figure's width instead of adding it on,
 * which is what reproduces the control:
 *
 *   Áreas    63.22 - 24 = 39.22 img -> 30.50 tall -> a 44.50 -> figure 51.50
 *   Entrar   71.92 - 24 = 47.92 img -> 47.92 tall -> a 61.92 -> figure 68.92
 *
 * `display` stays `inline-block`. The figure is 7.00px taller than the anchor in
 * BOTH control panels, and that is the baseline descent of an inline-block in a
 * 26px line box; `block` would collapse it and cost 7px per heading.
 */
.serena-header__panel .elementor-image-box-img a {
	width: 100%;
	box-sizing: border-box;
}

/*
 * The Áreas icon is 12% OF ITS COLUMN, and shrinkable — the same shape as the
 * logo, one level down.
 *
 *   post-5993.css
 *     .elementor-element-b8150f4 .elementor-image-box-img { width: 12% }
 *   and its sibling `.elementor-image-box-content` is width:100%.
 *
 * 12 + 100 = 112%, so the wrapper is declared to overflow by exactly the
 * figure's own width, and both children shrink in proportion. Check against the
 * control, which is what turns this from a reading into a measurement:
 *
 *   vw 1100  column 550  ->  12% = 66,  overflow 66,  figure 66 x 550/616 = 58.929
 *            control's figure = 58.922
 *   vw 1280  column 590  ->  12% = 70.8, figure = 63.214
 *            control's figure = 63.219
 *
 * — two hundredths of a pixel from the flexbox arithmetic done by hand.
 *
 * `flex: 0 1 auto` is half the rule and was the whole reason a first attempt
 * failed. Ours was `0 0 auto`: the percentage was there, the figure could not
 * shrink, and it sat at the full 66px. That is the SECOND time in this issue
 * that a correct percentage measured wrong because the shrink was disabled — the
 * logo's other half was its sibling's `flex: 1 1 auto`. A declared width means
 * nothing until you know whether the box is allowed to give it back.
 *
 * Replaces `width: 63.22px`, which was this same figure measured at 1280 and
 * frozen — right where the gate looked and wrong across the whole 1025-1180 ramp.
 */
.serena-header__panel.submenu-areas .elementor-image-box-img {
	width: 12%;
	flex: 0 1 auto;
}

/*
 * ---- Two open questions from this issue, both now closed by the mechanism ----
 *
 * **The 1/64px on the icons.** With the image at `width: 100%` of a frozen
 * `63.22px` figure it came out one LAYOUT UNIT wider than the control —
 * 39.2188px = 2510/64 against 39.2031px = 2509/64 — because the two trees
 * rounded different quantities: the control derives the width from the height
 * and the asset's 450x350 box, we derived it from the figure. 1/64px is the
 * finest difference Chrome can express and it still moved every antialiased edge
 * of the icon, worth ~119 AE. Gone: `width: auto; max-width: 100%` puts us on the
 * control's own rounding path.
 *
 * **The 20 AE that could not be attributed.** While the icons were still being
 * diagnosed with an injected MASK — the control's numbers forced in at three
 * decimals — `panel-areas` at 1100 reduced to 20 AE and stopped. That was
 * recorded as NOT ESTABLISHED rather than explained, on the grounds that it was
 * at or below the precision of the mask itself and no measurement available at
 * the time could separate "residual in the code" from "limit of the diagnostic".
 *
 * It was the mask. With the mechanism in place and no mask at all, that cell is
 * 0 AE.
 *
 * Worth keeping, because the tempting move was the wrong one: 20 AE of subpixel
 * colour on two icons had an obvious plausible story (SVG rasterisation), and
 * writing it down would have left a FALSE CAUSE in this file permanently, with
 * a number next to it to make it look measured. The honest reading of an
 * instrument at its limit is "I cannot tell", and it costs nothing to say.
 *
 * ---- and the rule that generalises from all of it ----
 *
 * Three separate mechanisms in this file were rejected at some point on measured
 * evidence and later turned out to be right: `width: 12%` on the icons (twice,
 * for two different reasons), the shrink that `flex-shrink: 0` suppressed, and
 * the percentage on the logo. Every one of those rejections reasoned from
 * OUTPUTS — the numbers the layout produced — and every one dissolved when a
 * defect further upstream was fixed.
 *
 * **A mechanism ruled out by measuring outputs stays ruled out only while the
 * rest of the outputs are correct.** In a layout being reconstructed piece by
 * piece, that condition is false by definition until the last piece lands. Read
 * the declaration; measure to confirm it, not to discover it.
 */
.serena-header__panel.submenu-acceder .elementor-image-box-img {
	/*
	 * No width: `Entrar`'s figure is shrink-to-fit around its image, which is
	 * what the control declares (its only width rule for this figure is
	 * `45px` under 767). Replaces `71.92px`, the control measured at 1280.
	 */
	width: auto;
	/* The control has this margin in `Entrar` and NOT in `Áreas` — one of the
	   several places where the two panels genuinely differ. */
	margin-right: 10px;
}

.serena-header__panel .elementor-image-box-content {
	width: 100%;
}

.serena-header__panel .elementor-image-box-title {
	margin: 0 0 10px;
	font-family: Nunito, sans-serif;
	font-size: 14px;
	font-weight: 700;
	line-height: 16.8px;
	letter-spacing: 2px;
	text-transform: uppercase;
	color: var(--sc-coral);
}

/*
 * The LINK inside the title spaces its letters differently from the block that
 * holds it: 1.4px against the 2px above. Both values are read off the control,
 * not inferred.
 *
 *   .elementor-image-box-title        letter-spacing  2px     (block)
 *   .elementor-image-box-title a      letter-spacing  1.4px   (the anchor)
 *
 * The symptom was titles ~6% too wide, which a screenshot cannot explain: same
 * family, weight, size and transform. The widths said it was per-character —
 *
 *   Individual     10 ch   120.000 vs 126.000   +6.000  = 10 x 0.6
 *   Pareja          6 ch    83.406 vs  87.000   +3.594  =  6 x 0.6
 *   Usuarios        8 ch   108.203 vs 113.000   +4.797  =  8 x 0.6
 *   Profesionales  13 ch   157.203 vs 165.000   +7.797  = 13 x 0.6
 *
 * — and four independent lengths agreeing on 0.6px/char is unambiguous. But
 * that arithmetic only says the DIFFERENCE is 0.6; it does not say which
 * element carries the value, and the first fix put 1.4px on the block, where
 * the control has 2px. It measured identical because the block contains no text
 * of its own, so nothing lays out at that level — a correct pixel result from a
 * declaration in the wrong place. `getComputedStyle` on both nodes is what
 * separated them, and it was as available here as it was for the caret's fill.
 *
 * Worth noting because it looks like a coincidence and is not: 1.4px is exactly
 * 0.1em at the 14px declared above. Same "two rules landing on the same pixel"
 * shape as the 1180/50px case, harmless here only because neither the font size
 * nor the spacing varies with the viewport.
 */
/*
 * ⚠ The FOURTH place in this issue where the control reaches a similar-looking
 * result by a different route per panel — after icon width, icon margin, column
 * spacing and layout direction.
 *
 * The two row panels share every other title property, and differ in exactly one:
 *
 *   .submenu-areas    title line-height 16.8px  -> anchor box 30.797 tall
 *   .submenu-acceder  title line-height 26px    -> anchor box 40 tall
 *
 * (7px of padding above and below in both cases: 16.8 + 14 = 30.8, 26 + 14 = 40.)
 *
 * Ours applied 16.8 to both, which sat the `Entrar` titles 13.656px too high
 * inside a wrapper that aligns to `flex-end`. Writing one rule for both panels
 * is what hid it: A UNIFORM DIFFERENCE DOES NOT IMPLY A UNIFORM CAUSE, and the
 * corollary bites here — a uniform RULE does not imply a uniform control.
 */
.serena-header__panel.submenu-acceder .elementor-image-box-title {
	line-height: 26px;
	/*
	 * And no bottom margin here, unlike `Áreas`. Measured on the control:
	 *
	 *   .submenu-areas    title margin 0 0 10px  -> content box 40.797 tall
	 *   .submenu-acceder  title margin 0         -> content box 40     tall
	 *
	 * The margin is inside the content box, so carrying it over inflated the box
	 * by 10px and then the centring below divided the error in half. Both halves
	 * of this panel's vertical offset come from here.
	 */
	margin-bottom: 0;
}

/*
 * `Entrar` centres its image box; `Áreas` bottom-aligns it. Sixth route.
 *
 * Measured on the control, per panel:
 *
 *   panel             wrapper top   wrapper h   align-items   content top
 *   .submenu-areas       105.219       51.500   flex-end         115.922
 *   .submenu-acceder     115.219       68.922   center           129.672
 *
 * `Áreas` is reproduced by the shared `flex-end` rule and measures identical to
 * the control box for box, so the shared rule is right and this is the exception.
 *
 * Check on `Entrar`, and note it uses OUR wrapper height, not the control's:
 * ours is 68.906 where the control's is 68.922, because the icon inside differs
 * by one 1/64px layout unit (see the note on the icon sizing). Centring divides
 * whatever height it is given, so the check has to use the height the rule will
 * actually see: (68.906 - 40) / 2 = 14.453, and 115.219 + 14.453 = 129.672 —
 * the control's content top to the thousandth, reached by dividing our own box
 * rather than by writing an offset down.
 */
.serena-header__panel.submenu-acceder .elementor-image-box-wrapper {
	align-items: center;
}

.serena-header__panel .elementor-image-box-title a {
	color: inherit;
	text-decoration: none;
	/* 1.4px here, 2px on the block above — see the note on that rule. */
	letter-spacing: 1.4px;
}

/* ---- Panel internals: the link list ----
   `.clean-list` itself is defined in the compiled style.css (list-style:none,
   margin-left:0) and is deliberately NOT redefined here — only hung off. */
.serena-header__panel .clean-list a {
	display: inline-block;
	padding: 7px 12px;
	border-radius: 9px;
	font-family: Nunito, sans-serif;
	font-size: 14px;
	font-weight: 600;
	line-height: 26px;
	text-transform: uppercase;
	color: var(--sc-link);
	text-decoration: none;
	transition: background 0.18s ease, color 0.18s ease, transform 0.18s ease;
}

.serena-header__panel .clean-list a:hover {
	background: rgba(255, 148, 114, 0.13);
	color: var(--sc-coral);
	transform: translateX(3px);
}

.serena-header__panel .clean-list .h5 {
	font-family: Nunito, sans-serif;
	font-size: 14px;
	font-weight: 600;
	line-height: 20px;
	letter-spacing: 2.5px;
	text-transform: uppercase;
	color: var(--sc-magenta);
}

/* ---- Panel internals: the "Recursos gratuitos" headings ---- */
.serena-header__resource .elementor-heading-title {
	font-family: Nunito, sans-serif;
	font-size: 14px;
	font-weight: 700;
	line-height: 14px;
	text-transform: uppercase;
	color: var(--sc-magenta);
}

.serena-header__resource .elementor-heading-title a {
	display: inline-block;
	padding: 7px 12px;
	border-radius: 9px;
	color: inherit;
	text-decoration: none;
	transition: background 0.18s ease, color 0.18s ease, transform 0.18s ease;
}

.serena-header__resource .elementor-heading-title a:hover {
	background: rgba(255, 148, 114, 0.13);
	color: var(--sc-coral);
	transform: translateX(3px);
}

/* ============================================================
   6. The CTA — mobile only

   Measured: at 1280 the anchor's box is 0x0, and `tests/chrome.spec.ts`
   asserts it is not readable there. Surfacing it on desktop is a design change
   and needs sign-off on captures, so `display:none` is the faithful answer.
   ============================================================ */
.serena-header__cta {
	display: none;
}

/* ============================================================
   7. <=1024px — the mobile bar

   The breakpoint is the one `header-modern.css` already used, and the one
   Elementor's `e-n-menu-tablet` switches on: below it the horizontal nav
   becomes a drawer, and the CTA appears.
   ============================================================ */
@media (max-width: 1024px) {
	/*
	 * `position:sticky`, not `fixed`.
	 *
	 * The control pins the bar with `position:fixed` and pays for the hole it
	 * leaves in the flow with a second, in-flow copy of the whole bar rendered
	 * underneath it — two elements, same 390x58.1875 box, same paint. The native
	 * markup renders the bar once, so `fixed` would take those 58.1875px out of
	 * the document and pull every mobile page up by exactly that much: the
	 * +1394px bug's smaller twin, with the sign flipped.
	 *
	 * `sticky` pins identically from scroll 0 (the header is body's first child,
	 * so its containing block is the whole document) while still occupying its
	 * own space. Height is deliberately left to the content — 10 + 38.1875 + 10
	 * = 58.1875 — so it cannot drift from the logo it is measured against.
	 */
	.serena-header {
		display: flex;
		/*
		 * `!important`, and it is not hygiene fodder: delete it and the mobile
		 * header silently stops sticking. Enumerated, not guessed —
		 *
		 *   header, .header_inner_left, footer.uncover { position: relative !important }
		 *   -- wp-content/themes/bridge/css/responsive.min.css
		 *      @media only screen and (max-width: 1000px)
		 *
		 * Bridge pins `position` on the BARE `header` tag with `!important`, and
		 * `!important` beats any normal declaration whatever its specificity.
		 * That is why every OTHER property of this block arrived — z-index 9999,
		 * margin-bottom 0, height auto, all three measured on the served page —
		 * and `position` alone did not: it is the only one Bridge overrides.
		 * Only `!important` beats `!important`, and `.serena-header` (0,1,0)
		 * then beats `header` (0,0,1).
		 *
		 * Why the control never hit this and we did: in the control the element
		 * that pins is a `div.sticky-header` INSIDE the <header>, so Bridge's
		 * tag-anchored rule never reaches it. This markup pins the <header>
		 * itself. Nothing was done wrong — the native markup, being simpler, is
		 * exposed to a rule the Elementor markup dodged by an accident of
		 * structure. Any future native chrome hung on a bare tag is exposed the
		 * same way.
		 *
		 * The band: Bridge's rule cuts at 1000px and this block at 1024px, so
		 * between 1001 and 1024 the sticky already worked. The defect only shows
		 * at <=1000px — which is why 390 is what exposed it, and why it went
		 * unnoticed since #25: that cell had never been captured.
		 */
		position: sticky !important;
		top: 0;
		height: auto;
		margin-bottom: 0;
		padding: 10px 0;
		align-items: center;
		/* Applies between in-flow items only, and the drawer is not one. */
		column-gap: 20px;
		background: #fff;
		z-index: 9999;
	}

	/*
	 * The group: 75% of the viewport here, 64% below 768 (block at the end of
	 * this file). Both read off `post-5993.css`.
	 *
	 * ⚠ `gap` is the one value here taken from the RENDERED result rather than
	 * from the declaration, and it is flagged because that is normally what this
	 * file refuses to do. The control declares `column-gap: 10px` below 768 and
	 * renders 20; declares 20 between 768 and 1024 and renders 40 — Elementor
	 * adds a widget margin on top of the gap. Reproducing the declaration alone
	 * would put the toggle 10px out. So the effective spacing is reproduced,
	 * measured at both breakpoints. It is a constant, not a viewport-derived
	 * quantity, so it carries none of the #38 risk — but it is an output, and
	 * outputs are what this file is otherwise careful not to copy.
	 */
	.serena-header__bar-end {
		display: flex;
		align-items: center;
		box-sizing: border-box;
		width: 75%;
		justify-content: flex-end;
		gap: 40px;
	}

	/* Visual order is logo, CTA, toggle; DOM order is logo, [toggle, CTA], nav.
	   The nav is out of flow below, so it takes part in neither. */
	.serena-header__cta {
		order: 2;
	}

	.serena-header__toggle {
		order: 3;
	}

	.serena-header__logo {
		margin: 5px 0 5px 20px;
		/* The desktop percentage does not belong here: below 1025 the image
		   carries its own `calc(30vw - 20px)` (which already reproduces the
		   control exactly — measured identical at 360, 390, 430 and 480), and a
		   59px wrapper around a 97px image would overflow it. */
		width: auto;
	}

	/* 30% of the viewport minus the container's own 20px inset — which is what
	   Elementor's 30%-wide logo column resolves to, and exactly 97px at 390.
	   Capped at the asset's natural width so wider tablets do not upscale it. */
	.serena-header__logo img {
		width: calc(30vw - 20px);
		max-width: 180px;
		height: auto;
	}

	/*
	 * The drawer. Closed means `display:none`: `chrome.spec.ts` fails a header
	 * whose navigation is readable at 390 without opening it (the `open-nav`
	 * negative control), and #26 needs it out of flow so opening it cannot
	 * resize the bar.
	 */
	.serena-header__nav {
		display: none;
		position: absolute;
		left: 0;
		/*
		 * The drawer hangs off the TOGGLE's bottom edge, not the bar's.
		 *
		 * `top: 100%` was wrong by 3.094px on every label, every divider and the
		 * drawer's own bottom edge — thirteen points measured, all +3, with zero
		 * horizontal offset. The control anchors elsewhere:
		 *
		 *     nav.e-n-menu          top 18.094, height 22   (wraps the toggle)
		 *       div.e-n-menu-wrapper  position:absolute; top:22px; margin-top:15px
		 *     -> 18.094 + 22 + 15 = 55.094
		 *
		 * i.e. the toggle's bottom edge plus 15px. Ours resolved against the bar's
		 * bottom edge (58.188) instead, and 58.188 - 55.094 = 3.094.
		 *
		 * `50%` is the toggle's own centre: the bar's padding is symmetric
		 * (10px 0) and it centres its items, so the toggle's midline IS the bar's
		 * midline whatever the bar's height. From there:
		 *
		 *     50%  + 11px  (half the toggle's declared 22px height)
		 *          + 15px  (the margin the control gives its drawer — the SAME 15
		 *                   that used to sit here as `margin-top`; it is inside
		 *                   the 26 now, so do NOT add it again or it counts twice)
		 *     = calc(50% + 26px)
		 *
		 * Verified: 58.188 / 2 + 26 = 55.094, exactly where the control's drawer
		 * starts.
		 *
		 * ⚠ Why `50%` and not `calc(100% - 3.094px)`, which also lands on 55.094:
		 * that 3.094 decomposes into 10px of the bar's bottom padding plus 8.094px
		 * of centring slack, and the slack depends on the LOGO's height, which is
		 * `calc(30vw - 20px)`. So the literal is only correct at 390px wide — and
		 * the matrix measures exactly one mobile width. It would have passed the
		 * gate BY CONSTRUCTION and been wrong on every other phone. A gate only
		 * proves what it measures, and a constant fitted to the measurement is
		 * indistinguishable from a correct one from inside the gate. The form
		 * above has no such term: it self-adjusts with the bar, as the control does.
		 */
		top: calc(50% + 26px);
		width: 100vw;
		margin: 0;
		padding: 0;
		flex-direction: column;
		background: #fff;
		/*
		 * The shadow the open drawer casts on the page below it.
		 *
		 * READ from the control, not fitted to the pixels. The pixel profile said
		 * a shadow was there — pure black, alpha falling monotonically from 0.192
		 * to 0 over ten rows, proven to be opacity rather than a colour because
		 * all three channels scaled by the same factor (202/250 = 190/235 =
		 * 186/231 = 0.808). But a shadow fitted to that profile would have closed
		 * the number without being the same shadow: the profile was measured over
		 * THIS page's pink, and the day the page behind it changes colour a fitted
		 * curve stops matching and nobody knows why. The computed value is a fact;
		 * a fitted curve is an imitation that happens to agree on one background.
		 *
		 * The measured 0.192 against the declared 0.2 is the blur's own falloff.
		 *
		 * ⚠ In the control it is NOT declared on the element that holds the menu
		 * (`ul.e-n-menu-heading`, which reports `box-shadow: none`) but on its
		 * PARENT, `div.e-n-menu-wrapper` — the same element the `top` above is
		 * derived from. Reading only the obvious node would have returned `none`
		 * and concluded there was no shadow at all; the whole ancestor chain had
		 * to be read. `filter` is `none` and `border-radius` is `0` everywhere in
		 * that chain, so there is no corner shape and no drop-shadow to reproduce.
		 *
		 * Worth 3 508 px — 88% of everything that was still differing when this
		 * was written.
		 */
		box-shadow: rgba(0, 0, 0, 0.2) 0 5px 5px 0;
		z-index: 2147483640;
		overflow: hidden auto;
		max-height: calc(100vh - 100%);
	}

	.serena-header__nav.is-open,
	.serena-header__toggle[aria-expanded="true"] + .serena-header__nav {
		display: flex;
	}

	.serena-header__items {
		flex-direction: column;
		justify-content: flex-start;
	}

	.serena-header__item {
		width: 100%;
		flex-direction: column;
	}

	/* One row per item: text left, caret right, full-width divider. Ported from
	   header-modern.css's <=1024 block. */
	.serena-header__title {
		/*
		 * `border-box`, and it is load-bearing twice over.
		 *
		 * 1 · The drawer row overflowed the viewport. `width: 100%` resolves to
		 *     390px of CONTENT box and the 24px of padding were added outside it:
		 *     438 = 390 + 24 + 24, measured on all three routes, identically. The
		 *     control reaches the same look the other way round — its link has NO
		 *     padding (18px of bare line box) and an ancestor supplies the 24px
		 *     inset, so its row is 342 = 390 - 48 at x=24. Same result, opposite
		 *     mechanism: padding INSIDE the width against padding OUTSIDE it.
		 *
		 * 2 · The same class lands on two different elements, and without this
		 *     they disagreed WITH EACH OTHER. Measured inside one open drawer:
		 *
		 *       button  "Áreas" / "Recursos gratuitos" / "Entrar"     390px
		 *       a       "Psicólogas" / "Empresas" / "Bono regalo"     438px
		 *
		 *     Because the UA stylesheet gives <button> `border-box` and leaves <a>
		 *     at `content-box`. Three rows of our own drawer were 48px wider than
		 *     the other three — a defect of ours, not a divergence from the
		 *     control, and one we were about to paper over without knowing it was
		 *     there. Stating the box model explicitly is what stops the element
		 *     type deciding the layout.
		 *
		 * The vertical rhythm was already right and is not touched: the row pitch
		 * measured 98.00px on both trees, on all three routes.
		 */
		box-sizing: border-box;
		width: 100%;
		flex-direction: row;
		align-items: center;
		justify-content: space-between;
		padding: 15px 24px;
		background: #fff;
		border-bottom: 1px solid rgba(0, 0, 0, 0.07);
	}

	.serena-header__title-text {
		font-size: 15px;
		line-height: 18px;
		text-align: left;
	}

	.serena-header__panel-toggle::after {
		width: 15px;
		height: 15px;
	}

	/* In the drawer the panel is an accordion body, in normal flow inside the
	   already-out-of-flow drawer — not the full-bleed desktop overlay. */
	.serena-header__panel {
		position: static;
		flex-direction: column;
		gap: 0;
		padding: 0 20px;
		box-shadow: none;
		border: 0;
		border-radius: 0;
	}

	/*
	 * The toggle.
	 *
	 * Same reasoning as the caret: the control paints Elementor's `menu-bar`
	 * eicon as an inline <svg> at 22x22 in #9D9D9D, the native markup has only a
	 * screen-reader label inside the button, and the markup is not this issue's
	 * to change. Same path, same viewBox, same colour, drawn as a background.
	 */
	.serena-header__toggle {
		display: block;
		flex: 0 0 auto;
		width: 22px;
		height: 22px;
		padding: 0;
		border: 0;
		background-color: transparent;
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 1000 1000'%3E%3Cpath fill='%239D9D9D' d='M104 333H896C929 333 958 304 958 271S929 208 896 208H104C71 208 42 237 42 271S71 333 104 333ZM104 583H896C929 583 958 554 958 521S929 458 896 458H104C71 458 42 487 42 521S71 583 104 583ZM104 833H896C929 833 958 804 958 771S929 708 896 708H104C71 708 42 737 42 771S71 833 104 833Z'/%3E%3C/svg%3E");
		background-position: center;
		background-size: contain;
		background-repeat: no-repeat;
		-webkit-appearance: none;
		appearance: none;
		cursor: pointer;
		/*
		 * 20px of trailing space here, 10px below 768 — what the control's toggle
		 * widget carries as `padding-right` at each breakpoint.
		 *
		 * The toggle's DISTANCE FROM THE EDGE is not declared anywhere. It falls
		 * out of the CTA-and-toggle pair being centred inside a box that is a
		 * percentage of the viewport, which is what `.serena-header__bar-end` now
		 * reproduces.
		 *
		 * This used to read `margin-right: 39.953px`, under a comment that had
		 * ALREADY WORKED OUT the mechanism — "Elementor packs the CTA and the
		 * toggle inside a sub-container that is 64% of the viewport wide with its
		 * content centred" — and then declined to build it, because "the native
		 * markup has no such container to centre anything in", reproducing the
		 * resulting inset instead. The diagnosis was right and the conclusion was
		 * to freeze its output at one width. The container was three lines of
		 * markup away.
		 *
		 * What that cost: the control's inset runs 28.562 at 360, 39.953 at 390,
		 * 55.156 at 430, 74.156 at 480. Ours was 39.937 at every one of them —
		 * correct at 390, the only phone width the matrix measures, and wrong on
		 * every other phone in the world.
		 */
		margin-right: 20px;
	}

	/*
	 * Open, the toggle becomes a coral X.
	 *
	 * The control keeps BOTH glyphs in the DOM (`e-n-menu-toggle-icon e-open` and
	 * `… e-close`) and swaps which one shows, recolouring the icon from
	 * rgb(157,157,157) to rgb(255,148,114). Path, viewBox and colour below are
	 * lifted from the served DOM — `e-eicon-close`, viewBox 0 0 1000 1000 — not
	 * redrawn, because an X drawn by hand is an X that differs in every pixel.
	 *
	 * ⚠ The eighth instance of this issue's pattern. `serena-header.css` already
	 * had an `[aria-expanded="true"]` variant for the PANEL caret and none for
	 * this toggle: the same omission, in the same file, by the same author, and
	 * invisible until the drawer could be opened at all. A style for a state
	 * nothing can reach is a style nobody has ever seen.
	 */
	.serena-header__toggle[aria-expanded="true"] {
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 1000 1000'%3E%3Cpath fill='%23FF9472' d='M742 167L500 408 258 167C246 154 233 150 217 150 196 150 179 158 167 167 154 179 150 196 150 212 150 229 154 242 171 254L408 500 167 742C138 771 138 800 167 829 196 858 225 858 254 829L496 587 738 829C750 842 767 846 783 846 800 846 817 842 829 829 842 817 846 804 846 783 846 767 842 750 829 737L588 500 833 258C863 229 863 200 833 171 804 137 775 137 742 167Z'/%3E%3C/svg%3E");
	}

	.serena-header__cta {
		display: block;
		/* No `margin-left: auto`: the pair is CENTRED inside
		   `.serena-header__bar-end`, and an auto margin would shove it back
		   against the right edge. */
	}

	/*
	 * Beating Elementor's `.elementor-button` / `.elementor-size-sm` defaults
	 * (padding 8px 16px, radius 3px, background #69727d), which still load on
	 * every page because the page CONTENT is Elementor even when the header is
	 * not. Won on specificity — 0,4,1 against their 0,2,0 — rather than with
	 * `!important`: header-modern.css needed the hammer because it was competing
	 * inside Elementor's own header, and this file is not.
	 */
	.serena-header .serena-header__cta a.elementor-button {
		display: inline-block;
		padding: 8px 10px 7px;
		border: 0;
		border-radius: 40px;
		font-family: Nunito, sans-serif;
		font-size: 15px;
		font-weight: 700;
		line-height: 15px;
		letter-spacing: 0.5px;
		text-transform: uppercase;
		text-align: center;
		text-decoration: none;
		color: #fff;
		background-color: transparent;
		background-image: linear-gradient(-45deg, var(--sc-gold) 0%, var(--sc-coral) 100%);
	}

	.serena-header .serena-header__cta a.elementor-button .elementor-button-content-wrapper {
		display: flex;
		justify-content: center;
	}
}

/* ============================================================
   Scrolled state (the "sticky effects")
   ------------------------------------------------------------
   The compiled, unbuildable style.css wires the whole scrolled
   look — opaque background, shadow, backdrop blur, shrink and
   logo scale — to `.elementor-sticky--effects`:

     header .sticky-header.elementor-sticky--effects        { bg, shadow, blur }
     header .sticky-header.elementor-sticky--effects > .elementor-container
                                                           { min-height: h * .8 }
     header .sticky-header.elementor-sticky--effects .logo img { scale(.9) }

   Two ways out, and the choice matters beyond this issue:

   (a) have #26's JS emit `elementor-sticky--effects` on the native
       header. Free, zero duplication — and it leaves the native
       header depending on an Elementor class name forever.
   (b) restate the four declarations under a class of our own.

   (b), deliberately. The lesson from the icon derivatives (#35) is
   that a dependency which resolves silently is worse than one you
   can see: it survives the thing that maintained it and then breaks
   without a trace. The duplication costs four declarations against
   a file that can never change again — its Sass sources are gone —
   so the two cannot drift.

   ⚠ CONTRACT WITH #26: the sticky JS must toggle `is-stuck` on
   `.serena-header`. Nothing else reproduces this state, and the
   `sticky` capture is one of the cells the matrix cannot reach until
   that JS exists — so if this breaks, nothing detects it until #26.

   Note the compiled rules also key on `> .elementor-container`, an
   element the native markup does not have; the shrink is restated
   here on the bar itself.
   ============================================================ */
.serena-header{
  /* 7rem on desktop, 6.4rem below 768 — the compiled stylesheet sets both and
     the second only inside a media query. Extracting a declaration without the
     context that conditions it is how the mobile background got missed. */
  --serena-header-height:7rem;
  --serena-shrink-to:.8;
  --serena-chrome-transition:.45s cubic-bezier(.4,0,.2,1);
  transition:background-color var(--serena-chrome-transition),
             backdrop-filter var(--serena-chrome-transition),
             box-shadow var(--serena-chrome-transition);
}
.serena-header__logo img{ transition:transform var(--serena-chrome-transition); }

/* The background the compiled stylesheet gives `.sticky-header`, restated here
   because we no longer wear that class. Route-dependent on purpose: on post
   routes a dark full-bleed hero sits directly under the header, and without an
   opaque bar the navigation is read on top of the photograph. Measured across
   all 11 routes of the matrix: white on the two post routes, transparent on the
   other nine. */
/* ---- Backgrounds, swept exhaustively from the compiled stylesheet ----------
   Five declarations set a background under `header .sticky-header`, not the two
   an eyeball search turns up. The mobile one is invisible on nine of the eleven
   routes, because only /blog/ and the psicologa single put an image directly
   under the header; everywhere else a light page hides a transparent bar. Same
   mechanism that hid the desktop one on the post routes, one breakpoint down. */
.serena-header{ background-color:transparent; }
.serena-header:hover{ background-color:#fff; }
body.single-post .serena-header{ background-color:#fff; }

@media (min-width:320px) and (max-width:767px){
  .serena-header{
    --serena-header-height:6.4rem;
    background-color:#fff;
  }
}

.serena-header.is-stuck{
  background-color:#fff;
  box-shadow:0 4px 33px 1px rgba(0,0,0,.07);
  -webkit-backdrop-filter:saturate(180%) blur(20px);
  backdrop-filter:saturate(180%) blur(20px);
  min-height:calc(var(--serena-header-height) * var(--serena-shrink-to));
}
/* Desktop only: the compiled rule lives inside @media (min-width:1025px). */
@media (min-width:1025px){
  .serena-header.is-stuck .serena-header__logo img{ transform:scale(.9); }
}

/* ============================================================
   The mobile accordion: this issue is a DESKTOP-ONLY change

   Everything #26 measured and fixed lives at >=1025px — the three mega-menu
   panels as full-bleed overlays. Below 1024px the same panels are accordion
   bodies inside the drawer, and that state is captured by NOTHING: `matrix.mjs`
   runs the three `panel-*` states on desktop only, and its `drawer` state opens
   the hamburger without ever expanding a body. A whole rendering mode with no
   gate on it.

   ## Why this block exists

   Eight of the declarations this issue introduces are not intrinsically
   desktop-only — column widths, title metrics, icon sizing, the open caret's
   colour — so they landed on the accordion too, unmeasured and unasked for.
   This block puts each of them back to what the branch rendered before, so the
   change is a provable no-op below 1025px.

   ## What is actually wrong down there, measured

   The accordion was ALREADY far from the control before this issue touched it,
   which is the finding worth keeping. Drawer opened at 390, one body expanded,
   against the control:

     panel      HEAD (before #26)   with #26      panel height ctrl vs ours
     Áreas          24 868 AE       24 909 AE       622.031  vs  623
     Recursos       21 412 AE       21 427 AE       277      vs  247
     Entrar         20 904 AE       20 897 AE       150      vs  177.813

   So this is a pre-existing defect of the #24/#25 markup and CSS, worth ~21-25k
   AE per panel, on a state no gate has ever looked at. It is NOT this issue's to
   fix — #26 is the header's behaviour and the desktop panels — and fixing it
   blind, without the gate that would prove it, is how the +10px of cause A
   survived five rounds. It gets its own issue, with these numbers.

   Without this block the change would have moved that broken state by
   1 237 / 5 891 / 5 699 AE in a direction nobody had measured. Moving an
   unmeasured state is not neutral just because it was already wrong.
   ============================================================ */
@media (max-width: 1024px) {
	/* The overlay's row layout and its centring are desktop affordances. */
	.serena-header__panel {
		justify-content: center;
	}

	.serena-header__panel.submenu-recursos {
		align-items: normal;
	}

	/* Half-width columns only make sense side by side; stacked, they are rows. */
	.serena-header__column {
		flex: 0 1 auto;
		box-sizing: content-box;
	}

	.serena-header__panel.submenu-acceder .serena-header__column {
		padding: 10px 0;
	}

	/*
	 * The desktop icon mechanism does not belong here. Below 1025 the panels are
	 * accordion bodies inside the drawer — a state no capture reaches (#40) and
	 * one this work is deliberately a no-op on. These restore what the branch
	 * rendered there before the percentages went in.
	 */
	.serena-header__panel .elementor-image-box-img {
		flex: 0 0 auto;
	}

	.serena-header__panel.submenu-areas .elementor-image-box-img {
		width: 63.22px;
	}

	.serena-header__panel.submenu-acceder .elementor-image-box-img {
		width: 71.92px;
	}

	.serena-header__panel .elementor-image-box-img img {
		width: 100%;
		max-width: none;
		height: auto;
	}

	/* Let the anchor inherit the block's 2px again. */
	.serena-header__panel .elementor-image-box-title a {
		letter-spacing: inherit;
	}

	.serena-header__panel.submenu-acceder .elementor-image-box-title {
		line-height: 16.8px;
		margin-bottom: 10px;
	}

	.serena-header__panel.submenu-acceder .elementor-image-box-wrapper {
		align-items: flex-end;
	}

	/* The open caret's darker fill was read off the control at 1280. */
	.serena-header__panel-toggle[aria-expanded="true"]::after {
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 320 512'%3E%3Cpath fill='%234F4F4F' d='M177 159.7l136 136c9.4 9.4 9.4 24.6 0 33.9l-22.6 22.6c-9.4 9.4-24.6 9.4-33.9 0L160 255.9l-96.4 96.4c-9.4 9.4-24.6 9.4-33.9 0L7 329.7c-9.4-9.4-9.4-24.6 0-33.9l136-136c9.4-9.5 24.6-9.5 34-.1z'/%3E%3C/svg%3E");
	}
}

/* ============================================================
   Phone widths: the group narrows and its content centres

   `post-5993.css` declares `--width: 64%` and `--justify-content: center` for
   the CTA-and-toggle container below 768, against 75% / flex-end above it. Both
   read, not fitted.

   This is the whole of issue #39: the toggle's distance from the right edge is
   a consequence of this box, not a property of the toggle. Verified against the
   control at 360, 390, 430 and 480 — see the note on `.serena-header__toggle`.
   ============================================================ */
@media (max-width: 767px) {
	/*
	 * THE SAME DECLARATION THAT WAS REVERTED IN `ead98ab55`, SCOPED (#43).
	 *
	 * `2f22023bb` put this on the BASE `.serena-header` rule and the 97-cell
	 * matrix came back with 70 cells over tolerance, 12 of the 19 ledger cells at
	 * new values and 3 captures unreadable. The mechanism was right and the
	 * ELEMENT was right; what was wrong was the SCOPE. Read that history before
	 * touching this line — two similar commits are not one redundant commit.
	 *
	 * ## Why the row has to be allowed to wrap at all
	 *
	 * The control's row and ours carry the SAME negative slack, measured on both
	 * trees by differential (`flex-shrink: 0`, then re-measure):
	 *
	 *     overflow = column-gap − (100% − Σ --width) × container
	 *
	 * Below 768 the two columns are 30% + 64% = 94%, so the overflow is
	 * `20 − 0.06w`, crossing zero at 333.33. Predicted 0.8 / 0.08 / 0.02 at
	 * 320 / 332 / 333; measured 0.797 / 0.063 / 0.000 on BOTH trees, and 333 does
	 * not wrap — which fixes the operator as strict `>`. So under 333 the control
	 * resolves the overflow by wrapping and we resolved it by letting
	 * `flex-shrink` squeeze the second column, which is the whole of #43: 86
	 * against 56 at 320, 21px of height on every page at every route.
	 *
	 * ## Why 767 is read and not fitted
	 *
	 * It is the control's own boundary. Elementor's framework carries
	 * `.e-con{--flex-wrap-mobile:wrap}` and, inside `@media (max-width:767px)`,
	 * `.e-con.e-flex{--flex-wrap:var(--flex-wrap-mobile)}`. Above 767 `--flex-wrap`
	 * has no value, so `flex-wrap: var(--flex-wrap)` falls back to the initial
	 * `nowrap`. Confirmed on the element itself: the control's row reads `wrap` at
	 * 767 and `nowrap` at 768. Mirroring it here is exact, not approximate.
	 *
	 * ## ⚠ Why it must NOT extend past 767
	 *
	 * Between 768 and 1024 the columns are 25% + 75% = 100%, so the overflow IS
	 * the gap: +20.000px at every width, constant, and no viewport resolves it.
	 * Measured identical on both trees, down to the same compression split
	 * (4.609 / 15.391 at 800). BOTH rows would wrap there if allowed — the control
	 * included. The control is held in one row by its own `nowrap`, and nothing
	 * else. Grant permission above 767 and the bar wraps across the whole tablet
	 * band, which is exactly what the reverted commit did.
	 *
	 * Artefacts: `.f3-runs/issue43/flexrow3-CONTROL.json`, `flexrow3-NATIVE.json`,
	 * `wrapdecl-CONTROL.json`, `contraste-2b.json`.
	 */
	.serena-header {
		flex-wrap: wrap;
	}

	.serena-header__bar-end {
		width: 64%;
		justify-content: center;
		gap: 20px;
	}

	.serena-header__toggle {
		margin-right: 10px;
	}
}

/* ============================================================
   768–1024: the tablet band, where the control changes its logo column

   Read off `post-5993.css`, and the same shape as everywhere else in this file:

     .elementor-element-b0d82a0 (logo) { --width: 25% }   768–1024
                                       { --width: 30% }   <=767
     .elementor-element-98ee9dc (nav)  { --width: 75% }   768–1024
     .elementor-element-1cc348f (row)  { --padding-top/bottom: 10px } <=767
                                       { --padding-top/bottom: 0 }    768–1366

   25 + 75 = 100%, and the row adds a 20px column-gap on top, so once again the
   line is declared to overflow — by exactly the gap — and the two columns give
   it back in proportion. The logo's share is 20 x 0.25 = 5px. Checked against
   the control at three widths:

     vw 768   25% = 192      - 5 = 187      measured 187.406
     vw 900   25% = 225      - 5 = 220      measured 220.344
     vw 1024  25% = 256      - 5 = 251      measured 251.297

   and the image inside is the container's content (its 20px of left padding
   removed) capped at the asset's intrinsic 180. Which is why the bar RAMPS from
   768 to about 834 and is flat after: below 834 the container is narrower than
   180 and the image follows it; above, the cap takes over.

     vw     768     800     834    900    960   1000   1024
     ctrl  56.5   58.719    60      60     60     60     60

   The native was 80 across the whole band — `calc(30vw - 20px)` applied from the
   `<=1024` block, i.e. the <=767 rule stretched over a band that has its own.
   Every page in the band was 20px too long (#44).

   ⚠ Two regimes inside one band, which is why the new matrix cell sits at 800
   and not at 900. In the flat part a fitted `height: 60px` would pass at any
   width sampled there and be wrong from 768 to 834 with nothing to say so —
   #38 again, with the blind spot known in advance. A cell on the ramp is the
   only one that can tell a mechanism from a constant. The flat part is covered
   by `flow-sweep.mjs`, which samples 834, 900, 960, 1000 and 1024.
   ============================================================ */
@media (min-width: 768px) and (max-width: 1024px) {
	.serena-header {
		/* The row's 10px of vertical padding belongs to <=767 only. */
		padding: 0;
	}

	.serena-header__logo {
		width: 25%;
		box-sizing: border-box;
		/*
		 * 20px on the left and 5px above and below — and the two halves come from
		 * DIFFERENT elements on the control, which is why they are written as one
		 * padding here rather than as a margin.
		 *
		 *   .elementor-element-b0d82a0  (the 25% column)  padding: 0 0 0 20px
		 *     └ the logo widget inside it                 margin:  5px 0
		 *
		 * The horizontal inset has to be INSIDE the 25% (a margin would sit
		 * outside it and widen the line, changing the shrink); the vertical 10px
		 * has to be in the box's height, because that is what makes the bar
		 * `image + 10` tall. Our markup has one element where the control has two,
		 * so both land here.
		 *
		 * Getting this wrong is worth recording: a first attempt wrote `margin: 0`
		 * and the bar came out at exactly the image's height — 46.5 against the
		 * control's 56.5 — with the logo itself correct to the LayoutUnit. The
		 * width was right and the height was 10px short, which is this issue's
		 * recurring shape in miniature.
		 */
		padding: 5px 0 5px 20px;
		margin: 0;
	}

	.serena-header__logo img {
		width: auto;
		max-width: 100%;
		height: auto;
	}

	/*
	 * The toggle is 20px here and 22px below 768 — and, like the CTA underneath,
	 * the value we were applying across the whole `<=1024` block is the control's
	 * EXCEPTION rather than its rule.
	 *
	 *   control  vw 767 -> 22 x 22      vw 768 / 900 / 1024 -> 20 x 20
	 *
	 * Constant across the band, measured at three widths inside it.
	 *
	 * ⚠ Honest about provenance: unlike everything else in this block, the
	 * declaration behind 20px was NOT located. It is not a width/height rule in
	 * any stylesheet that matches the button — the CSSOM enumeration returns only
	 * a padding reset from `custom-pro-widget-mega-menu.min.css` — and
	 * `--e-n-menu-toggle-icon-size` is empty. It is most likely an inline style or
	 * an Elementor icon-size setting emitted somewhere the enumeration does not
	 * reach. So this is a value read off the CONTROL'S COMPUTED STYLE at three
	 * widths, not off its source, which is a weaker footing than the rest of this
	 * file and is said so rather than smoothed over.
	 */
	.serena-header__toggle {
		width: 20px;
		height: 20px;
	}

	/*
	 * The CTA's own type, and this one IS read from source:
	 *
	 *   post-5993.css  .elementor-element-c285d { font-size: 14px; padding: 9px 15px 8px }
	 *                  @media (max-width: 767px) { font-size: 15px; padding: 8px 10px 7px }
	 *
	 * So 14px is the base rule and 15px is the phone exception. Ours applied the
	 * exception across the whole `<=1024` block, which made the button 144.5x30
	 * where the control's is 148.5x31.
	 *
	 * Same specificity as the rule it overrides (0,4,1) and later in the file, so
	 * it wins on order rather than with `!important` — the reasoning already
	 * recorded on that rule.
	 */
	.serena-header .serena-header__cta a.elementor-button {
		font-size: 14px;
		padding: 9px 15px 8px;
		/*
		 * `1`, not the `1em` that applies below 768. Bridge's `.elementor-button`
		 * base declares `line-height: 1` and `post-5993.css` overrides only the
		 * size and padding in this band, so the base survives — while its <=767
		 * rule does say `line-height: 1em`. The two differ by half a pixel of text
		 * box (14 against 15) and half a pixel of vertical position, which is
		 * enough to redden every glyph in the button.
		 */
		line-height: 1;
		/*
		 * 7px, not the 40px pill of <=767 — the FOURTH declaration in this band
		 * where we were applying the phone exception over a band that has its own
		 * base rule. Measured on the control:
		 *
		 *   vw 390 -> 40px   767 -> 40px   768 -> 7px   900 -> 7px   1024 -> 7px
		 *
		 * At 31px tall a 40px radius clamps to a full pill, so the two shapes are
		 * a rounded rectangle against a capsule — 246 AE, all of it in two
		 * symmetric 123-pixel patches at the button's left and right ends, with
		 * the button's box (571.5, 148.5 x 31) already identical.
		 *
		 * ⚠ Same weaker provenance as the toggle's 20px above: no border-radius
		 * rule matching this anchor appears in any stylesheet the CSSOM
		 * enumeration can read, so this is the control's COMPUTED value at four
		 * widths rather than its source. Most likely an Elementor kit setting
		 * emitted outside the sheets that are reachable.
		 *
		 * And it is the fourth time in this band that measuring the wrong element
		 * hid the defect: the text span matched exactly — same x, same y, same
		 * 118.5 x 14 — while the BUTTON around it had the wrong corners. The span
		 * was the thing I compared; the button was the thing that was wrong.
		 */
		border-radius: 7px;
	}

	/*
	 * The drawer hangs 9px lower here, and the arithmetic is the same as the one
	 * already written for <=767 — only its two inputs change.
	 *
	 *   control  <=767    toggle 22 tall, wrapper margin-top 15  -> 50% + 11 + 15
	 *            768–1024 toggle 20 tall, wrapper margin-top 25  -> 50% + 10 + 25
	 *
	 * The toggle's midline is the bar's midline (the bar centres its items), so
	 * the offset is half the toggle plus the wrapper's own margin. Both values
	 * read: `top: 20px` and `margin-top: 25px` on `.e-n-menu-wrapper` at 768 and
	 * 900, against 22px/15px at 390.
	 */
	.serena-header__nav {
		top: calc(50% + 10px + 25px);
	}

	/*
	 * And the drawer's items use the DESKTOP type in this band, not the phone's:
	 *
	 *   control  vw 390 -> font-size 15px, line-height 18px
	 *            vw 768 / 900 -> font-size 17px, line-height 25.5px
	 *
	 * 17/25.5 is exactly `.serena-header__title-text`'s base — the same numbers
	 * `--sc-bar-h` is computed from. So this is not a new value, it is the base
	 * rule surviving into a band where the `<=1024` block was overriding it with
	 * the phone's.
	 *
	 * Fifth instance in this one band of the same mistake: the <=767 exception
	 * applied over a band that has its own base. Logo, toggle, CTA type, CTA
	 * corners, and now the drawer's type and anchor.
	 */
	.serena-header__title-text {
		font-size: 17px;
		line-height: var(--sc-title-lh);
	}
}