/**
 * Manager総研 TOP — Page Layout CSS (Phase 9-5E).
 *
 * Loaded only on the TOP page itself (functions.php kakeai_enqueue_assets(),
 * is_page('media')), after cards.css. Owns container/grid/hero/spacing —
 * the Page Layout responsibilities CLAUDE.md Phase 9-5D §15 / this Phase's
 * §16 explicitly keep out of cards.css (Component-only file).
 *
 * Built from live Production measurement (https://kakeai.co.jp/media/, CDP,
 * not reused from Phase 9-5D.2's Preview-based numbers — that Preview used
 * a flat 1176px demo container that never matched Production's real
 * section wrapper, which this file reproduces directly instead).
 */

.ly_m_wrapper {
	padding-left: 3%;
	padding-right: 3%;
}

/* Phase 9-5E.1 Correction (Known Issue #4): re-measured across an
   11-point breakpoint sweep (1440→375px) — unlike every other section's
   wrapper, the Hero wrapper carries ZERO horizontal padding at every
   width (confirmed: `.ly_m_container`'s left edge sits flush at x=0 below
   the 1176px cap, full-bleed; above it, the container's own `margin:0
   auto` centers it, not wrapper padding). Phase 9-5E's first pass
   wrongly let this wrapper inherit the shared `.ly_m_wrapper` 3% rule
   above, insetting the Hero slide where Production doesn't. */
/* Phase 9-5E.2 Correction (Human Review A): Human Review compared PC
   screens side by side and found Local had a plain white Hero — this
   `background-color` was never measured in Phase 9-5E/9-5E.1 (only
   padding/width were checked). Confirmed via CDP, constant at every
   width. */
/* Phase 9-5E.4 ROOT CAUSE (Human Re-Review): the Carousel's real clipping
   boundary on Production is THIS element (full viewport width, 1440px at
   1440px) — not `.swiper` (confirmed via full ancestor-chain geometry
   dump: Production's `.swiper`/`.swiper-wrapper` both compute
   `overflow: visible`, only this wrapper has `overflow: hidden`). Local
   had `overflow: hidden` on `.kakeai-top-hero-swiper` instead (1176px,
   the content-container-constrained width), clipping Previous/Next
   slides far earlier than Production — this, not the background color,
   was why the Carousel "stage" looked narrower than Production even
   though the navy background already spanned the full viewport. */
.ly_m_wrapper.kv {
	padding-top: 2rem; /* 32px, Production-measured */
	padding-bottom: 1.375rem; /* 22px, Production-measured */
	padding-left: 0;
	padding-right: 0;
	background-color: var(--media-color-primary);
	overflow: hidden;
}

/* Phase 9-5E.2 Correction (Human Review F): same miss as the Hero wrapper
   above — background-color was never checked. */
.ly_m_wrapper.is-top-tag {
	padding-top: 0;
	padding-bottom: 0;
	background-color: var(--media-color-gray-97);
}

/* Phase 9-5E.7 ROOT CAUSE (Human Re-Review, Featured Tag stacking at SP):
   confirmed via `CSS.getMatchedStylesForNode` — Production makes THIS
   wrapper (not `.bl_m_tag_box`) the horizontal scroll container at
   ≤767px (`overflow: auto`, `scrollWidth` 1270 vs `clientWidth` 390 at
   390px — a native browser scrollbar, no custom scrollbar CSS exists on
   Production to replicate). Paired with `.bl_m_tag_block { flex-flow:
   column }` and `.bl_m_tag_box { flex-wrap: nowrap }` below, the heading
   and the single-row tag list scroll together as one unit — this is
   Production's actual (if unusual) behavior, confirmed by scrolling it
   live and watching the heading move with the tags, not an assumption. */
@media (max-width: 767px) {
	.ly_m_wrapper.is-top-tag {
		overflow: auto;
	}
}

.ly_m_wrapper.top {
	padding-top: 2.5rem; /* 40px, Production-measured */
	padding-bottom: 0;
}

.media-article.bottom {
	padding-bottom: 5rem; /* 80px, Production-measured */
}

.ly_m_container {
	width: 100%;
	max-width: 1176px;
	margin: 0 auto;
}

/* ---------------------------------------------------------------------
 * Hero / Key Visual (.media-slide) — Swiper carousel. Production-measured
 * (not assumed): the card is `display:flex; flex-direction:row`
 * (image LEFT, text RIGHT, touching with no gap) at PC/Tablet — NOT a
 * stacked layout like the other card components — and only switches to a
 * stacked column at ≤767px. Fixed pixel card widths (not % of container)
 * at PC/Tablet: 776px (≥992px), 720px (768–991px); spaceBetween 24px,
 * loop + autoplay(4000ms) + pagination dots, no next/prev arrows
 * (Phase 9-5E.1 correction: custom-named `.bl_m_kv_slide_btn_left/_right`
 * navigation buttons DO exist — Phase 9-5E's first pass only searched for
 * Swiper's default `.swiper-button-*` class names and missed them).
 * ------------------------------------------------------------------- */
.kakeai-top-hero-swiper {
	position: relative;
}

/* Phase 9-5E.6 ROOT CAUSE (Human Re-Review): removing our own `overflow:
   hidden` declaration (Phase 9-5E.4) was not enough — Swiper's own bundled
   CSS independently sets `.swiper { overflow: hidden }` as its default, and
   this element still carries the plain `.swiper` class (added by the
   library itself), so that default kept clipping Previous/Next at the
   1176px `.swiper` boundary regardless of source order. Confirmed via
   `CSS.getMatchedStylesForNode` on Production: it overrides the exact same
   bundled default with a two-class selector, `.swiper.m_cms_article {
   overflow: visible }` — specificity (0,2,0), beating the bundled
   single-class rule (0,1,0) outright rather than relying on load order.
   This mirrors that technique with our own second class. */
.swiper.kakeai-top-hero-swiper {
	overflow: visible;
}

.kakeai-top-hero-swiper .swiper-wrapper {
	display: flex;
}

/* Phase 9-5E.3 ROOT CAUSE (Human Re-Review A/B/C): Swiper's own bundled
   CSS defaults every `.swiper-slide` to `width: 100%` (flex-shrink:0) —
   correct for numeric `slidesPerView`, but `slidesPerView: 'auto'` (used
   here, top.js) requires overriding that back to `width: auto` so each
   slide shrinks to its own content's width (`.bl_m_slide_card`, 776px)
   instead of stretching to the full 1176px swiper container. Found via
   `elementFromPoint()` sampling across the Hero viewport (not trusting
   `getBoundingClientRect()`/Swiper-params alone, per this round's
   instruction) — Local's slide element measured 1176px wide although its
   own card content was correctly 776px, leaving ~400px of empty slide
   space after each card that pushed every adjacent slide far outside the
   visible viewport (only one slide ever visible) and off-centered the
   active card within its own oversized slide (left-aligned content in a
   too-wide box, matching the reported "card appears left-shifted").
   Production's own `.swiper-slide` computes `width: auto` already — this
   was never an intentional Production behavior to diverge from, just a
   missed override. */
.kakeai-top-hero-swiper .swiper-slide {
	width: auto;
}

/* Nav arrows — Production-measured (1440px): 40×40px circle, white bg,
   1px solid #b8b8b8 border, centered vertically on the slide, centered
   horizontally on the active slide's own left/right edge (consistent
   with `centeredSlides:true` — confirmed the offset math: container
   center ± half the slide's own CSS width exactly reproduces Production's
   measured button position at both 1440px and 991px). Collapses to
   width:0 at ≤767px (Production's own mechanism — not display:none). */
.bl_m_kv_slide_btn_left,
.bl_m_kv_slide_btn_right {
	position: absolute;
	top: 50%;
	transform: translateY(-50%);
	width: 40px;
	height: 40px;
	display: flex;
	align-items: center;
	justify-content: center;
	border-radius: 100%;
	background-color: var(--media-color-white);
	border: 1px solid #b8b8b8;
	z-index: 10;
	cursor: pointer;
}

.bl_m_kv_slide_btn_svg {
	width: 12px;
	height: 12px;
}

.bl_m_kv_slide_btn_left .bl_m_kv_slide_btn_svg {
	transform: rotate(180deg);
}

.bl_m_kv_slide_btn_left {
	left: calc(50% - 388px - 20px); /* 776px slide / 2 + half button, ≥992px */
}

.bl_m_kv_slide_btn_right {
	right: calc(50% - 388px - 20px);
}

@media (max-width: 991px) {
	.bl_m_kv_slide_btn_left {
		left: calc(50% - 360px - 20px); /* 720px slide / 2 + half button */
	}

	.bl_m_kv_slide_btn_right {
		right: calc(50% - 360px - 20px);
	}
}

@media (max-width: 767px) {
	.bl_m_kv_slide_btn_left,
	.bl_m_kv_slide_btn_right {
		width: 0;
		height: 0;
		border: none;
		overflow: hidden;
	}
}

/* Human Review Correction (Phase 9-5E.3, point D): Production's own card
   has `background-color: rgb(255,255,255)` (white) — confirmed in Phase
   9-5E's original DOM walk but never actually applied in this rule, so
   the navy `.ly_m_wrapper.kv` background showed through the card's text
   area. Also removed `margin-right` here — it duplicated the 24px gap
   Swiper's own `spaceBetween` (top.js) already applies as an inline
   style on the parent `.swiper-slide`, doubling the gap to 48px. */
/* Phase 9-5E.8 ROOT CAUSE (Human Re-Review, SP Card height varies with
   title line count): confirmed via `CSS.getMatchedStylesForNode` AND a
   live client-side test (shortening the active slide's own title text
   in the DOM, no CMS/DB change) — Production's card height is NOT
   content-driven. `.bl_m_slide_card { height: 100% }` fills whatever
   height Swiper's own `.swiper-wrapper` flex-stretch already gives
   every `.swiper-slide` (stretched to the tallest slide among the 9
   real+duplicate DOM nodes, standard flex `align-items: stretch`
   default — unchanged, already correct). With the short-title DOM
   edit, Production's card/info position stayed frozen (366px,
   infoTop 403) while Local's shrank to fit the shorter title (300px,
   infoTop 335) — proof the card itself, not the slide/wrapper
   stretch mechanism, was the missing piece. `.bl_m_slide_card_cnt`'s
   existing `justify-content: space-between` (already correct, no
   change) is what then absorbs the slack between a shorter title and
   the info row pinned to the card's own now-fixed bottom edge. */
.bl_m_slide_card {
	display: flex;
	flex-direction: row;
	flex-shrink: 0;
	width: 776px; /* Production-measured, ≥992px */
	height: 100%; /* Production-measured — see ROOT CAUSE above */
	text-decoration: none;
	color: var(--media-color-text);
	background-color: var(--media-color-white);
}

.bl_m_slide_card_thumb {
	display: block;
	flex-shrink: 0;
	width: 61.6%; /* 478px of 776px, Production-measured */
	aspect-ratio: 1.91 / 1;
	overflow: hidden;
	border-radius: 4px;
	background-color: var(--media-color-gray-93);
}

.el_m_slide_card_img {
	width: 100%;
	height: 100%;
	object-fit: cover;
}

/* Phase 9-5E.2 Correction (Human Review C): the image/text gap is NOT a
   flex `gap` between thumb and cnt (confirmed via CDP: thumb's right edge
   and cnt's left edge are flush, 0px apart) — it's this element's OWN
   padding (24px top/bottom, ~24px left/right, Production-measured),
   which also pushes the text block's right edge in from the card's own
   edge symmetrically. Root-caused precisely rather than guessing a
   margin value, per this round's explicit instruction. */
.bl_m_slide_card_cnt {
	display: flex;
	flex-direction: column;
	justify-content: space-between;
	flex: 1 1 auto;
	min-width: 0;
	/* Phase 9-5E.7 correction: Production's left/right padding is
	   `3.1%` of the card's own width, not a fixed `1.5rem` — at the
	   776px PC card width the two are nearly identical (24.05px vs
	   24px, which is why PC Human Review never flagged this), but at
	   SP card widths (~367px) `1.5rem` was nearly DOUBLE Production's
	   actual ~11.4px, directly inflating the title/info text column
	   and, combined with the top/bottom padding below, the whole
	   card's height. Confirmed via `CSS.getMatchedStylesForNode` on
	   Production (`padding: 1.5rem 3.1%`). */
	padding: 1.5rem 3.1%;
	box-sizing: border-box;
}

/* Phase 9-5E.7 ROOT CAUSE (Human Re-Review): `h3.el_m_slide_card_ttl`
   (element+class, specificity 0,1,1) — plain `.el_m_slide_card_ttl`
   (0,1,0) was silently losing to Foundation's `.media-site h1..h6`
   rule (components.css, specificity 0,1,1: one class + one type
   selector beats one class alone), the same recurring specificity
   pattern fixed throughout cards.css. Foundation's
   `margin:0 0 var(--media-space-sm)` / `font-weight:700` /
   `line-height:var(--media-line-height-heading)` were winning over
   this rule's `margin:0` / `font-weight:600` / `line-height:1.7`,
   which is what produced the extra title-bottom spacing and the
   wrong weight/line-height Human Review found at SP (PC never showed
   it because title height differences there were masked by the much
   larger fixed card height). Confirmed via `CSS.getMatchedStylesForNode`
   — not assumed. */
h3.el_m_slide_card_ttl {
	margin: 0;
	font-size: 1.25rem; /* 20px, Production-measured */
	font-weight: 600;
	line-height: 1.7; /* 34px at 20px, Production-measured */
	color: var(--media-color-text);
}

.bl_m_slide_card_info {
	display: flex;
	flex-wrap: wrap;
	align-items: center;
	gap: 1.125rem 3.8%;
}

@media (max-width: 991px) {
	.bl_m_slide_card {
		width: 720px; /* Production-measured, 768–991px */
	}

	.bl_m_slide_card_thumb {
		width: 56%; /* 403px of 720px, Production-measured */
	}
}

@media (max-width: 767px) {
	/* Phase 9-5E.8 ROOT CAUSE, part 2: adding `.bl_m_slide_card { height:
	   100% }` (base rule above) alone was NOT enough — a live diagnostic
	   (shortening the active slide's own title via a client-side-only DOM
	   edit, no CMS/DB change) showed the SLIDE itself (not just the card)
	   still shrank to fit the shorter content, taking the card down with
	   it. Production overrides `.swiper-slide` from the base `height:
	   100%` (Swiper's own bundled default) to `height: auto` at exactly
	   this breakpoint (confirmed via `CSS.getMatchedStylesForNode` on the
	   live element, not the generic bundled rule). `height: auto` is what
	   correctly triggers `.swiper-wrapper`'s native flexbox
	   `align-items: stretch` (the default, already in place, unchanged)
	   to stretch every slide to match the tallest of the 9 real+duplicate
	   DOM nodes — `height: 100%` instead tries to resolve against the
	   wrapper's own auto/content-based height and collapses back to
	   content-fit sizing per slide, which is what was actually causing
	   the reported per-article height variance. Re-tested after this fix:
	   Local's shortened-title slide/card height stayed frozen exactly
	   like Production's own (366px, unchanged), confirming the fix. */
	.kakeai-top-hero-swiper .swiper-slide {
		height: auto;
	}

	.bl_m_slide_card {
		flex-direction: column;
		width: 100%; /* Production: full slide width at SP (slidesPerView:'auto' + no fixed px) */
	}

	.bl_m_slide_card_thumb {
		width: 100%;
	}

	/* Phase 9-5E.7 correction: the fabricated `margin-top: 1rem` gap
	   between thumb and cnt never existed on Production — confirmed via
	   fresh geometry dump (thumb.bottom and cnt.top are flush, 0px
	   apart, at both 390px and 375px). `gap` corrected from `0.75rem`
	   to `1rem`, matching Production's own `grid-row-gap: 1rem` at this
	   breakpoint (`CSS.getMatchedStylesForNode`, not assumed). */
	.bl_m_slide_card_cnt {
		padding-top: 1rem;
		padding-bottom: 1rem;
		gap: 1rem;
	}
}

@media (max-width: 479px) {
	/* Phase 9-5E.7 ROOT CAUSE (Human Re-Review, SP Card left-aligned):
	   Phase 9-5E.1's `width: 94%` put the inset on `.bl_m_slide_card`
	   itself — a block-level child of `.swiper-slide` (not a flex
	   container), so without any auto margins it simply left-aligned
	   at the slide's own left edge instead of centering, which is
	   exactly what Human Review saw ("カードが左寄りになっている").
	   Production never insets the CARD at all — it insets the SLIDE
	   (`.swiper-slide.bl_m_cms_article.is-kv { width: auto;
	   padding-left: 3%; padding-right: 3% }`, confirmed via
	   `CSS.getMatchedStylesForNode`), and the card then simply fills
	   100% of that already-centered, padded content box. Moving the
	   inset from the card's width to the slide's padding reproduces
	   Production's actual mechanism instead of visually approximating
	   it with a different one. */
	.kakeai-top-hero-swiper .swiper-slide {
		padding-left: 3%;
		padding-right: 3%;
	}
}

/* Swiper's bundled CSS sets `.swiper-pagination` to `position: absolute`
   by default, which (undetected until an actual screenshot was taken, not
   just a computed-style check) overlapped it on top of the SP date text
   instead of flowing below the slide. `div.ly_m_kv_slide_dot` (element+
   class, 0,1,1) is used instead of relying on enqueue order to beat
   Swiper's plain `.swiper-pagination` (0,1,0) — WordPress's dependency
   printer did not reliably put top.css after the Swiper stylesheet even
   with `kakeai-swiper` declared as a dependency, so this is resolved at
   the specificity level instead, the same pattern used throughout
   cards.css. No `!important` used. */
div.ly_m_kv_slide_dot {
	position: static;
	display: flex;
	justify-content: center;
	gap: 0.5rem;
	margin-top: 1.5rem;
}

/* Phase 9-5E.2 Correction (Human Review D): Production's own bullets are
   rectangular bars, not circles (Phase 9-5E/9-5E.1 never re-measured this
   — Swiper's bundled default circle shape was left as-is). Confirmed via
   CDP: 32×6px, border-radius:0, inactive bg gray-82 (rgb(209,209,209)),
   ACTIVE bg is a distinct light blue (rgb(117,139,253)) that doesn't match
   any existing design token — kept as a literal value rather than
   substituting the nearest token, since Production's own value is the
   source of truth here, not this theme's existing palette. gap:16px
   reproduces the measured `margin: 0 8px` per bullet (8px each side =
   16px between adjacent bullets). */
.ly_m_kv_slide_dot {
	gap: 1rem; /* 16px, Production-measured */
}

.ly_m_kv_slide_dot .swiper-pagination-bullet {
	width: 32px;
	height: 6px;
	border-radius: 0;
	background: var(--media-color-gray-82);
	opacity: 1;
	cursor: pointer;
	margin: 0;
}

.ly_m_kv_slide_dot .swiper-pagination-bullet-active {
	background: rgb(117, 139, 253);
}

/* ---------------------------------------------------------------------
 * Section heading divider (.bl_m_sec_ttl) — Human Review Correction
 * (Phase 9-5E.2, point H). Production's divider line is NOT a sibling
 * element or a pseudo-element — it's `border-bottom` + `padding-bottom`
 * on a wrapper DIV that contains the `<h2>` (confirmed via a direct
 * children walk of Production's container: `.bl_m_sec_ttl` wraps
 * `.el_m_sec_ttl`, width matches the full 1176px container). Added as a
 * wrapper in page-media.php's markup to match this exact structure
 * rather than approximating it with a sibling `<hr>` or a pseudo-element
 * on the heading itself.
 * ------------------------------------------------------------------- */
.bl_m_sec_ttl {
	border-bottom: 1px solid var(--media-color-gray-82);
	padding-bottom: 1.375rem; /* 22px, Production-measured */
	margin-bottom: 2.5rem; /* 40px, Production-measured gap to the grid below */
}

/* Phase 9-5E.7 correction: Production's SP typography for 新着記事 /
   おすすめ記事 / 特集 (all three measured identical via
   `CSS.getMatchedStylesForNode` — font-size:20px, font-weight:400,
   line-height:28px at every section) was never added; `h2.el_m_sec_ttl`
   (cards.css) carried only the PC value (32px/1.72) at every width.
   `h2.el_m_sec_ttl` (not `.el_m_sec_ttl`) is used here too, matching
   that rule's own specificity (0,1,1) so this override is guaranteed to
   win regardless of cards.css/top.css enqueue order, not just by being
   declared later. Divider (`border-bottom`) and the 40px gap to the
   grid below are unchanged — Production keeps both constant across
   breakpoints, only `padding-bottom` shrinks at this tier. */
@media (max-width: 767px) {
	.bl_m_sec_ttl {
		padding-bottom: 0.625rem; /* 10px, Production-measured */
	}

	h2.el_m_sec_ttl {
		font-size: 1.25rem; /* 20px, Production-measured */
		font-weight: 400;
		line-height: 1.4; /* 28px at 20px, Production-measured */
	}
}

/* ---------------------------------------------------------------------
 * 新着記事 / おすすめ記事 / 特集 grids. Column-count breakpoints
 * (992/480/479) re-measured fresh this Phase against the real Production
 * grid container (`.ly_m_cms_3col` / `.ly_cms_3col`), not assumed from
 * Phase 9-5D.2's Preview numbers. Confirmed: 新着/おすすめ記事 and 特集
 * use two DIFFERENT gap value sets (and the SP gap change runs in
 * opposite directions between them) — kept as separate classes rather
 * than one shared grid class.
 * ------------------------------------------------------------------- */
.kakeai-top-grid {
	display: grid;
	grid-template-columns: repeat(3, 1fr);
}

.kakeai-top-grid-latest,
.kakeai-top-grid-recommended {
	gap: 24px 2.05%; /* Production-measured */
}

.kakeai-top-grid-feature {
	gap: 32px 3.6%; /* Production-measured */
}

@media (max-width: 991px) {
	.kakeai-top-grid {
		grid-template-columns: repeat(2, 1fr);
	}
}

@media (max-width: 767px) {
	.kakeai-top-grid-latest,
	.kakeai-top-grid-recommended {
		gap: 32px 2.05%; /* Production-measured — row gap widens at ≤767px */
	}

	.kakeai-top-grid-feature {
		gap: 24px 3.6%; /* Production-measured — row gap narrows at ≤767px (opposite direction from the grid above) */
	}
}

@media (max-width: 479px) {
	.kakeai-top-grid {
		grid-template-columns: 1fr;
	}
}

.kakeai-top-cta {
	display: flex;
	justify-content: center;
	margin-top: 2.5rem;
}

/* Phase 9-5E.1 Correction (Known Issue #3): re-measured against Production
   (not a design-token approximation) — identical at every breakpoint
   (1440/991/768/390/375 all returned the same values, confirmed via CDP),
   so no responsive override is needed. Hover: bg→navy, text→white, border
   stays navy (same pattern as Tag Pill's hover, Phase 9-5D.1 Issue #5).
   Scoped to this TOP-only class, not a Shared Component or global button
   style. */
/* `a.kakeai-top-cta-link` (element+class, 0,1,1) rather than the plain
   class (0,1,0): this is always an `<a>`, so Foundation's
   `.media-site a { text-decoration: underline; }` (0,1,1) was beating a
   single-class `text-decoration: none` here too — confirmed via CDP,
   the same specificity pattern found repeatedly throughout cards.css. */
a.kakeai-top-cta-link {
	display: block;
	width: 15rem; /* 240px, Production-measured */
	height: 3.625rem; /* 58px, Production-measured */
	box-sizing: border-box;
	padding: 0.875rem 0; /* 14px 0px, Production-measured */
	border: 1px solid var(--media-color-primary);
	border-radius: 8px;
	background-color: transparent;
	color: var(--media-color-primary);
	font-size: 1rem; /* 16px, Production-measured */
	font-weight: 600;
	line-height: 1.75; /* 28px at 16px, Production-measured */
	text-align: center;
	text-decoration: none;
	transition: color 0.2s, background-color 0.2s;
}

.kakeai-top-cta-link:hover {
	background-color: var(--media-color-primary);
	color: var(--media-color-white);
}

/* ---------------------------------------------------------------------
 * 注目タグ heading + tag list layout — Human Review Correction
 * (Phase 9-5E.2, point G). Production's `.bl_m_tag_block` is
 * `display:flex; flex-direction:row; align-items:center;` (heading and
 * tag list side by side, heading vertically centered against the
 * possibly-multi-row tag list) — Phase 9-5E's markup already nested the
 * heading and `.bl_m_tag_box` inside this wrapper div, but never gave it
 * this layout, so it fell back to plain block stacking.
 * ------------------------------------------------------------------- */
/* Human Review Correction (Phase 9-5E.3, point 2): the vertical spacing
   owner is NOT `.ly_m_wrapper.is-top-tag` (confirmed 0px padding on
   Production itself) — it's `.bl_m_tag_block`'s own `padding: 24px 0px`.
   Section height, wrapper padding, and tag content height (85.59px) were
   all already correct/matching before this fix; only this block's own
   padding was missing, which is why the section still measured the
   correct overall height but with no breathing room around the content. */
.bl_m_tag_block {
	display: flex;
	align-items: center;
	gap: 10px 1.4%; /* Production-measured */
	padding: 1.5rem 0; /* 24px, Production-measured */
}

.bl_m_tag_block .el_m_tag_ttl {
	white-space: nowrap; /* Production-measured — prevents the heading wrapping inside the flex row */
}

/* Phase 9-5E.7 correction: Production switches `.bl_m_tag_block` from
   row (PC, unchanged above — PC Human Review PASS) to column at ≤767px,
   and `.bl_m_tag_box` (cards.css, shared across other Tag Pill List
   contexts that DO still wrap — not edited here per this round's Scope
   Control) from wrap to a single nowrap row so its pills overflow
   horizontally instead, which is what the wrapper above then scrolls.
   Scoped to `.media-tag` (this page's Featured Tag section only) so the
   shared component's own default wrapping behavior elsewhere is
   untouched.

   Self-caught regression during QA: an earlier version of this rule
   also set `width: 100%` on `.bl_m_tag_box`. On Production the
   equivalent flex-wrap container (`.ly_m_cms_tag.is-highlight`) carries
   NO width constraint — only an unrelated ancestor div does — so it
   sizes to its own content and is free to grow past the viewport.
   Giving `.bl_m_tag_box` a literal `width: 100%` here instead pinned
   its own box to the (fixed, ~367px) container width, and with
   `flex-wrap: nowrap` the browser satisfied that constraint by
   shrinking every individual pill (each pill's default
   `flex-shrink: 1`, same as Production's) down to a sliver — causing
   each pill's own text to wrap internally into a tall narrow column,
   confirmed on screenshot. `flex-shrink: 0` on the pills themselves
   reproduces Production's actual visual result (full-size,
   unsquished pills genuinely overflowing the nominal box, clipped and
   scrolled only by `.ly_m_wrapper.is-top-tag` above) without needing
   any width override here at all. */
@media (max-width: 767px) {
	.bl_m_tag_block {
		flex-flow: column;
		justify-content: flex-start;
		align-items: flex-start;
	}

	.media-tag .bl_m_tag_box {
		flex-wrap: nowrap;
	}

	.media-tag .bl_m_tag_box .bl_m_tag {
		flex-shrink: 0;
	}
}