/**
 * R3.7D.1 -- Expertise "Planning + Programming" (post 32) Featured Text alignment, eyebrow size,
 * and body prose width.
 *
 * Both rules below live in WordPress's native Additional CSS (Customizer `custom_css` post, theme
 * `hello-elementor` -- not a git-tracked/enqueued fgma-core stylesheet; confirmed live, same source
 * already identified for the R3.7D.1 Row 43 quote-underline fix) and are shared, unscoped selectors
 * that apply to `Project_Component_Renderer::render_featured_text()`'s output regardless of which
 * CPT renders it -- Project (e.g. St. Charles Police Station, Bailey's Shelter, ~158 rows total) and
 * Expertise both share this exact component/renderer/CSS.
 *
 * Shared-scope verification (this round): post 32 is the ONLY currently-published Expertise post
 * whose flex_components include a featured_text row -- there is no second real Expertise record to
 * compare for internal consistency. Project's own featured_text usage was NOT diagnosed this round
 * (no Production-parity data for it), so both fixes below are scoped to `body.single-expertise`
 * only -- the same `body.single-{post_type}` ancestor-scoping convention this codebase's own
 * Additional CSS already uses elsewhere (e.g. `body.single-project .fgma-quote__attribution`) --
 * rather than editing the shared flat selectors directly, so Project's featured_text rendering is
 * completely unaffected either way.
 *
 * --- Finding 1: alignment ---
 * The shared rule reads `.fgma-component--featured-text{ padding-inline:var(--fgma-gutter-inset); }`.
 * At the diagnosed 1568px viewport, `--fgma-gutter-inset` (`clamp(1.8125rem,-2.7424rem +
 * 16.9484vw,24.375rem)`) computes to ~222px -- matching the reported DEV left edge (~226px) almost
 * exactly. `--fgma-gutter` (`clamp(1.8125rem,.5381rem + 4.7418vw,8.125rem)`) computes to ~83px at
 * the same viewport -- matching the reported Production left edge (~82px) almost exactly, and is
 * the same token `.fgma-expertise-other-areas__inner` (a real surrounding Expertise section) already
 * uses for its own left-edge padding. `max-width`/`margin` (which control the block's own centering,
 * not its left-edge offset here since `--fgma-content-max` is wider than any real viewport) are left
 * completely untouched, and the body copy's own typography is untouched.
 *
 * --- Finding 2: eyebrow typography ---
 * The shared rule reads `.fgma-featured-text__eyebrow{ font-size:var(--fgma-step-4); }` -- the exact
 * same token `.fgma-featured-text__body` uses, an intentional-at-the-time but Production-incorrect
 * choice (that rule's own comment already flagged this as an open question). At 1568px, `--fgma-
 * step-4` computes to ~38px -- matching the reported DEV eyebrow (~36px) almost exactly. `--fgma-
 * step-0` (`clamp(1rem,.9643rem + .1786vw,1.25rem)`) computes to ~18px at the same viewport --
 * matching the reported Production eyebrow (~20px) closely, and is the same token the analogous
 * `.fgma-column-copy__eyebrow` "label" role already uses elsewhere in this same stylesheet. Only
 * `font-size` changes here -- family/weight/color (already correct per this round's own brief) and
 * the separate `.fgma-featured-text__eyebrow + .fgma-featured-text__body` adjacent-sibling rule
 * (which retypes the BODY when an eyebrow is present, and is not part of either finding) are left
 * completely untouched.
 *
 * --- Finding 3 (follow-up): body prose width ---
 * `.fgma-featured-text__body` carries no width constraint of its own -- it simply fills its
 * already-fixed (Finding 1) `.fgma-component--featured-text` container, which at the diagnosed
 * 1568px viewport is far wider than Production's own measured prose column (~1404px on DEV vs.
 * Production's ~1023-1050px). Confirmed no `html`/`:root` font-size override exists anywhere on this
 * site (Additional CSS, theme reset.css/theme.css, or Elementor's base-desktop.css all searched
 * live) -- the browser default root is a plain 16px, so `64rem` resolves to exactly 1024px,
 * matching Production's measured range. A fixed rem value (not a fluid `--fgma-step-*`/`--fgma-
 * gutter-*` token, none of which target a prose measure at all) is deliberate here: this is a
 * one-off body-copy line-length constraint, not a spacing/typography-scale value, so there is no
 * existing design-system token to prefer over a literal. `max-width` only -- the container's own
 * padding/alignment (Finding 1) is untouched, and no other property changes.
 */
body.single-expertise .fgma-component--featured-text {
    padding-inline: var(--fgma-gutter);
}

body.single-expertise .fgma-featured-text__eyebrow {
    font-size: var(--fgma-step-0);
}

body.single-expertise .fgma-featured-text__body {
    max-width: 64rem;
}