/* ============================================================================
   rhythm.css — THE VERTICAL RHYTHM BAND SYSTEM.  Lane: `r3:vertical-rhythm`.
   Founder trace FT-20260819 §R3-B (B01…B07) and §R3-D (D01, D02, D04).
   ----------------------------------------------------------------------------

   FT-20260819 B01, verbatim:
     "Just make it taller on pretty much every section... I'm on a MacBook Pro
      and I don't like that I can see multiple sections at once. I just want
      more empty space at the top and bottom of each."

   FT-20260819 B07, which is the ARCHITECTURE and overrides any fixed number:
     "When we talk about going edge to edge from a vertical and width
      perspective, it needs to be set for the BREAKPOINTS OF THE DEVICE ITSELF,
      so it's dynamic. It shouldn't be a fixed width or fixed height, it should
      be designed around the breakpoint. On desktop it should scale so you're
      always seeing the height and width be proportional to the screen size of
      the user."

   ============================================================================
   THE MEASUREMENT THAT MADE THIS NECESSARY — not an impression, a capture.
   ============================================================================

   Every section was scrolled so its own top sat at the viewport top — the BEST
   case, the one alignment at which a section has the most of the screen to
   itself — and the set of [data-mk-slug] elements intersecting the viewport was
   read back.  `review/rhythm/shots.py`, capture in
   `review/rhythm/shots/before-1728x1030/_visible.json`:

     viewport 1728 x 1030 (16-inch MacBook Pro, Chrome)
       01-who-why        sees 2   01-who-why, 02-who-why-b
       02-who-why-b      sees 2   02-who-why-b, 03-unique
       04-ecology        sees 1
       07-building       sees 1
       08-recovery       sees 2   08-recovery, 09-recovery-42
       14-amenities      sees 1
       17-amenities-54   sees 2   17-amenities-54, 18-cta-expand
       21-logos-footer   sees 2   18-cta-expand, 21-logos-footer

   FIVE OF EIGHT SHOW TWO SECTIONS AT THE MOST FAVOURABLE SCROLL POSITION THERE
   IS.  The three that show one are exactly the three already expressed as
   `100svh` (04, 07, 14).  Every failure is a section authored as a fixed
   `900px`, `891px` or as content-hug.  That is the whole diagnosis: 900 is the
   FIGMA FRAME HEIGHT, and a 900px frame is a drawing surface while a 900px
   section is a promise about what else is on screen at the same time.  This is
   P-D12-1 (`founder-trace/helix/D12.md`) applied to the other sixteen sections
   instead of only to 03.

   ============================================================================
   THE RULE — one expression, three rungs
   ============================================================================

       min-height: max(<floor>, <k> x 100svh)

   The `svh` term is B07: the band tracks the device, so a taller screen gets a
   taller section and the proportion is preserved.  The floor is P-D12-2: a bare
   viewport term REGRESSES on a short laptop (a 14-inch MacBook Pro leaves
   ~850px, which is LESS than the authored 900), so the floor is stated as the
   ratio applied to the authored 900 and is therefore traceable:

       --mk-band-1     max( 900px, 100svh)   900 x 1     one screen, exactly
       --mk-band-12    max(1080px, 120svh)   900 x 1.2   one screen + breathing
       --mk-band-135   max(1215px, 135svh)   900 x 1.35  D12's 1200, now fluid

   `k = 1.2` is the smallest ratio that satisfies B01 at every viewport, and it
   is derived rather than chosen: for a section to have empty space at BOTH ends
   while its content occupies the middle, the band must exceed the viewport by
   at least the space it is meant to add.  At 1.2 the surplus is 20% of the
   screen — 206px at 1030, split 103/103 — which is the smallest surplus that
   reads as deliberate rather than as a rounding error.  It is one token; if the
   founders want more air it is one number, in one place, for the whole page.

   `--mk-band-135` keeps D12's own decision alive.  D12 shipped
   `max(100vh, 1200px)` for 03-unique with the ambiguity recorded ("1200 is MY
   proposal ... if the founders want 1080, 1350 or 120vh it is a one-value
   change").  FT-20260819 is that answer arriving as an architecture rather than
   as a number: 1200 becomes `max(1215px, 135svh)`, which is 1215 on the 14-inch
   and 1391 on the 16-inch instead of 1200 on both.

   ============================================================================
   SCOPE — why every rule here is >= 1000px, and that is a decision not a gap
   ============================================================================

   B07 says "mobile and tablet are separate cases".  `css/_band-xs.css`
   (691-999) and `css/_band-mobile.css` (<=690) already own those two rungs and
   already carry deliberate height rules there (`_band-xs.css:146` pins
   `.mk-whowhyb` to 900, `:174` pins `.mk-amenities` to 900; `_band-mobile.css`
   §1 hands `min-height: inherit` down the amenity chain).  This sheet is linked
   AFTER those six band sheets, so an unscoped rule here would silently beat
   them.  Everything below therefore lives inside `@media (min-width: 1000px)`,
   which is Salient's own desktop edge and the same edge the fluid container
   switches at (`review/fluid/FLUID-SYSTEM.md` §1).

   ============================================================================
   WHY THIS FILE EXISTS AT ALL, RATHER THAN 12 EDITS IN 12 SECTION SHEETS
   ============================================================================

   Two reasons, in order of weight.

   1. IT IS ONE SYSTEM AND IT SHOULD HAVE ONE HOME.  B01 is a statement about
      the PAGE, not about twelve sections that happen to agree.  Spread across
      twelve files the ratio cannot be changed in one move, cannot be read in
      one place, and the next founder comparative ("a bit more air") becomes
      twelve edits and twelve chances to diverge.  Three tokens and a table of
      assignments is the whole system.

   2. ONE WRITER PER ARTIFACT.  Round 3 runs `r3:building-slider`,
      `r3:recovery-plan`, `r3:amenities`, `r3:scroll-feel` and others
      concurrently, and they own 07, 08-13, 14-17 and 04 respectively.  Twelve
      section-sheet edits from this lane would collide with four other lanes on
      files they are actively rewriting.  A single sheet loaded last overrides
      by cascade position without touching a byte another lane owns, and it
      names every override so the fold-back is mechanical.

   FOLD-BACK: every §2 rule is a candidate to move into its section's own sheet
   once the concurrent round closes.  §3 and §4 are DEFECT overrides and should
   be folded back into the file that caused them — named in each block.

   NOT TOUCHED, DELIBERATELY — these are in FT-20260819's "WHAT LANDED" list or
   are another lane's live surface, and B01's "pretty much every section" does
   not license regressing a section the founder praised:
     00-hero          "hero nav/text/logo animate in" — already 100vh
     04-ecology       already exactly 100svh; C01/C02 are `r3:scroll-feel`'s
     07-building      already exactly 100svh; D03 is `r3:building-slider`'s
     14-amenities     "really full screen, I feel immersed" — already 100svh
     18-cta-expand    "really beautiful" — already viewport-proportional
                      (REQ-XR-3: 900/1280 = 1012.5/1440 = 45/64, proven by BOTH
                      artboards, the one element that scales with WIDTH)
   ========================================================================== */


/* ==========================================================================
   §1. THE TOKENS
   ========================================================================== */

@media (min-width: 1000px) {
  .mk-page {
    --mk-band-1:   max( 900px, 100svh);
    --mk-band-12:  max(1080px, 120svh);
    --mk-band-135: max(1215px, 135svh);
  }
}


/* ==========================================================================
   §2. THE ASSIGNMENTS
   ========================================================================== */

@media (min-width: 1000px) {

  /* --- 01-who-why · B02 -------------------------------------------------
     "Who-and-why text block: more vertical space above and below before the
      video section appears."

     MEASURED BEFORE: 651px at 1512x850 and at 1728x1030 — the ONE section on
     the page whose height does not respond to the viewport at all, because it
     is content-hug with `padding-block: 120px`.  At 1030 that puts 379px of the
     video section on screen underneath it, which is the single worst instance
     of B01 on the page.

     `align-content: center` and NOT more padding.  Padding is a fixed number
     and would have to be re-picked at every viewport, which is the thing B07
     forbids.  Centring the content inside a viewport-proportional band gives
     "empty space at the top AND the bottom" as an identity, at every height, in
     one declaration.  `display: grid` (not flex) because the section's children
     are Salient rows that rely on `width: 100%` block behaviour; grid's default
     `justify-items: stretch` preserves it exactly, where flex would shrink-wrap
     them. */
  .mk-page .mk-who-why {
    min-height: var(--mk-band-12);
    display: grid;
    align-content: center;
  }

  /* --- 02-who-why-b · B03 (height half) ---------------------------------
     "The video section (lady in black dress) must be taller."

     `height`, not `min-height`, because `.mk-whowhyb__card` is
     `position: absolute; inset: 0` and `.mk-whowhyb__text` is `height: 100%`:
     the whole section is a layer stack that resolves against a DEFINITE height.
     A `min-height` leaves `height: auto` and the percentage chain collapses —
     the same class of failure D12 recorded when one link of 03's `height: 100%`
     chain was missed and `.column-image-bg` measured 1px tall.

     The caption is `justify-content: flex-end`, so every pixel this adds lands
     ABOVE the caption and none of it moves the caption off its 48px inset. */
  .mk-page .mk-whowhyb {
    height: var(--mk-band-12);
  }

  /* --- 03-unique · B01 + D12 --------------------------------------------
     Was `max(100vh, 1200px)` in 03-unique.css §B8.1, shipped with the founder
     ambiguity recorded.  Same shape, now on the token, so 03 moves with the
     rest of the page instead of being the one hand-tuned section. */
  .mk-page .mk-unique,
  .mk-page .mk-unique > #mk03_intro > .row_col_wrap_12 {
    min-height: var(--mk-band-135);
  }

  /* --- 08-recovery · B04 (the intro band) --------------------------------
     "Recovery-plan sections: markedly taller. Currently the sections above and
      below stay in view."

     Three boxes, and all three have to move together or the section tears: the
     row carries the 900 `min-height`, and BOTH columns carry a definite
     `height: 900px` on their `.vc_column-inner` (08-recovery.css §1.2 / §1.5)
     because the photograph's 4px padding band and the copy's CENTER alignment
     both resolve against it.  Raising only the row leaves two 900px columns
     top-aligned inside a taller band. */
  .mk-page [data-section="08-recovery"] > .wpb_row.vc_row-flex > .row_col_wrap_12.span_12 {
    min-height: var(--mk-band-12);
  }
  .mk-page [data-section="08-recovery"] .mk-recovery__images > .vc_column-inner,
  .mk-page [data-section="08-recovery"] .mk-recovery__copy   > .vc_column-inner {
    height: var(--mk-band-12);
  }

  /* --- 09 / 10 / 11 / 12 / 13 · B04 · CEDED TO `r3:recovery-plan` --------
     THIS LANE DELIBERATELY SETS NO PANEL HEIGHT, AND THE HISTORY IS THE POINT.

     An earlier revision of this file raised `.mk-rplan__panel` to
     `var(--mk-band-12)` for B04 ("Recovery-plan sections: markedly taller"),
     including the five ID-SCOPED restatements needed to actually win the
     cascade.  It was measured working: 09 went 2060 -> 2484 and 11/12/13 went
     3090 -> 3720 at 1728x1030.

     It was then MEASURED AGAIN and found inert, because `r3:recovery-plan` had
     landed `--mk-rplan-panel-h: 80svh` on `.mk-rplan` in the same minutes
     (09-recovery-42.css §D06), taking the panels to 824px at 1030.  That lane
     is answering a LATER and MORE SPECIFIC founder instruction about this exact
     element:

       D06  "Recovery images are TOO TALL. Reduce height so a hint of the SECOND
             image is visible — like the donor."

     B04 asks for a taller SECTION; D06 asks for a shorter PANEL, and the two
     are not in conflict once you notice they name different boxes — but they
     ARE in conflict about which lane owns `.mk-rplan__panel`, and the answer is
     not this one.  Their rule is already breakpoint-driven (`80svh`, and their
     comment cites B07 by name), so B07 is satisfied there without this lane
     touching it.  Leaving a losing override in place would have been worse than
     useless: inert today, and a silent fight the first time either specificity
     moved.

     WHAT THIS LANE STILL DOES FOR B04 is the band ABOVE the stack — 08-recovery,
     the intro, immediately above — which is the pair the co-visibility capture
     actually caught ("08-recovery sees 2: 08-recovery, 09-recovery-42").

     FILED, NOT ASSUMED: REQ-VR-2 asks `r3:recovery-plan` to express
     `--mk-rplan-panel-h` against this file's `--mk-band-*` scale so the page has
     ONE vertical ratio rather than two that happen to agree, and asks the
     founders to rule on B04-vs-D06 for the section total, which their change
     takes DOWN (09: 2060 -> 1660 at 1030) while B04 asked for it to go up. */

  /* --- 16-amenities-52 · B05 --------------------------------------------
     "Amenities taller so the map is not yet visible."  The map is
     17-amenities-54 (Playa Hermosa / Playas del Coco / Guanacaste / LIR); the
     section above it is 16, the features-and-amenities board, authored
     `min-height: 900px` on the section AND on its frame — the frame carries it
     too because `.mk-amenities52__frame` is the positioning context for the
     hover-tooltip cursor and must be the full band. */
  .mk-page .mk-amenities52,
  .mk-page .mk-amenities52__frame {
    min-height: var(--mk-band-12);
  }

  /* --- 17-amenities-54 · B01 --------------------------------------------
     The map band, authored 891 (the one section whose Figma height is not 900).
     One screen exactly: it is a map, not a reading surface, so it wants to fill
     the viewport rather than exceed it.  The floor is its own authored height,
     not 900, so nothing about the plate's anamorphic stretch changes below
     891px of viewport. */
  .mk-page .mk-map54 {
    min-height: max(891px, 100svh);
  }

  /* --- 21-logos-footer · B06 --------------------------------------------
     "Backed By + footer should together be roughly full viewport height on a
      MacBook Pro."

     This is the one item in R3-B that names a TARGET rather than a direction,
     and the target is exactly `--mk-band-1`: one screen, no more.  At 1030 the
     authored 900 leaves 130px of 18-cta-expand's photograph on screen above it,
     which is precisely why it does not read as "the footer" yet.

     The surplus has to be ABSORBED, not appended.  A bare `min-height` on a
     block container leaves the extra at the bottom, below the copyright line,
     which would push the ink up and leave dead space under it.  Column flex
     with the body growing puts the surplus inside the body, between the link
     grid and the newsletter — the two places the design already has air. */
  .mk-page .mk-footer {
    min-height: var(--mk-band-1);
    display: flex;
    flex-direction: column;
  }
  .mk-page .mk-footer > .mk-footer__body {
    flex: 1 1 auto;
    display: flex;
    flex-direction: column;
    justify-content: space-between;
  }
}


/* ==========================================================================
   §3. R3-D LAYOUT DEFECTS THAT ARE VERTICAL-RHYTHM ADJACENT
   ========================================================================== */

@media (min-width: 1000px) {

  /* --- D01 · what-makes-unique, the awkward headline break ---------------
     "left text container slightly narrower + more right margin; at her width
      'what makes a' / 'safe stay unique' breaks awkwardly."

     SOLVED BY SWEEPING THE REAL ELEMENT, NOT BY ESTIMATING GLYPH WIDTHS.
     `review/rhythm/probe-sweep.js` walks the h2's max-width from 620px down to
     300px in 5px steps and reads back which words share a line
     (`review/rhythm/sweep.json`, 1512x850):

         <= 620   2 lines   "What makes a safe" / "stay unique?"   <- SHIPPED
         <= 495   2 lines   "What makes a" / "safe stay unique?"   <- ASKED FOR
         <= 450   3 lines   "What makes a" / "safe stay" / "unique?"

     The founder's break exists in exactly one window: **455 … 495px**.  475 is
     its midpoint, so there is 20px of headroom on each side — enough that a
     font-metric or optical-sizing drift cannot flip the break either way, and
     that headroom is the reason for choosing the midpoint over the widest
     value that happens to work.

     THE COLUMN BOX IS NOT TOUCHED, AND THAT IS THE POINT.  `.mk-unique__copy`
     stays `flex: 0 0 837px` and the images column stays pinned at x = 837.  The
     founder asked for "narrower + MORE RIGHT MARGIN", which is one change, not
     two: capping the TEXT GROUP at 475 inside an unchanged 597px content box
     produces 122px of extra right margin as its remainder.  Narrowing the
     column instead would have moved the seam, and with it the kitchen
     photograph and the absolutely-positioned coastline card — a composition
     that is not in this founder trace and must not move. */
  /* RETIRED 2026-09-02 (founder): "I do not want an absolute width set on
     this … everything we do is percentages and ratios." The measure is now
     responsive, keyed to the coastline card's overhang — see the final block
     of sections/03-unique.css. The break analysis above is kept as history. */

  /* --- D02 · "ecological considerations" must fit ONE LINE ---------------
     "must fit ONE LINE and today drops onto the picture at smaller widths."

     MEASURED FAILURE.  At 1024x800 the title renders 193.5px tall on a 96.77px
     line box — TWO LINES.  Its natural single-line width is 846.06px and the
     container's content box is 784px (`review/rhythm/before-breaks.json`).  The
     shipped rule is 04-ecology.css:919 `clamp(48px, 7.5vw, 96px)`, inside
     `@media (max-width: 1279px)`.

     WHY A vw-KEYED CLAMP CANNOT WORK HERE, WHICH IS THE REAL ROOT CAUSE.
     Between 1000 and 1279 the container's content box is `100vw - 240px`, so it
     grows at the SAME rate as the viewport but from a smaller base: content/vw
     climbs from 0.760 at 1000 to 0.8125 at 1280.  A font-size keyed to a flat
     `7.5vw` therefore outruns the box it has to fit in, and it is furthest
     ahead at the BOTTOM of the band — 1024, which is where the defect was
     reported.  The type was scaled against the viewport while its constraint is
     the container.  `review/fluid/FLUID-SYSTEM.md` §3 prescribes
     `clamp(floor, (fig/1280)*100vw, fig)` for display type and that is exactly
     `7.5vw`; the prescription is right for type whose box is the viewport and
     wrong for type whose box is the container, and this file is the first place
     that distinction has had to be made.

     THE RAMP IS FITTED TO A MEASURED CURVE, NOT DRAWN BETWEEN TWO POINTS.
     `probe-sweep.js` also measures the title's natural width at ten font sizes,
     which gives the width-per-px-of-font ratio and shows it is NOT constant —
     optical sizing widens the face as it shrinks:

         fs   40     48     56     64     72    76.8    80     88     96    104
         w/fs 11.63  11.50  11.36  11.23  11.10 11.02  10.96  10.83  10.70  10.56

     Solving `natural(fs) = 100vw - 240px` against that table gives the largest
     font-size that fits at each width — 67.8 at 1000, 70.1 at 1024, 78 at 1100,
     82.9 at 1152, 88.6 at 1200, 97.4 at 1280.  The ramp below sits under every
     one of those, and it is verified AT them rather than interpolated between
     them (see `review/rhythm/after-fit.json`).

         clamp(66px, calc(10.7142857vw - 41.1428571px), 96px)

     reads 66 at 1000, 68.6 at 1024, 76.7 at 1100, 82.3 at 1152, 87.4 at 1200
     and **exactly 96.0 at 1280** — so it meets the shipped desktop value at the
     artboard with no step, and the `clamp` ceiling holds 96 from 1280 upward.
     BOTH ARTBOARDS ARE THEREFORE BYTE-UNCHANGED: at 1280 and at 1440 this
     computes to the same 96px / 121px the section already shipped, which is
     what keeps `review/fidelity.py` (which measures at 1280) honest.

     `white-space: nowrap` is the STRUCTURAL guarantee sitting behind the
     numeric one.  The requirement is "ONE LINE"; a font-size that fits is an
     arithmetic argument that one line is possible, and nowrap is the assertion
     that one line is what happens.  If the copy is ever re-worded longer, the
     title overflows visibly — which is a bug you can see — instead of silently
     dropping a second line onto the photograph, which is the bug being fixed.

     line-height is restated as the ratio 121/96 so the box tracks the ramp; at
     96px it evaluates to exactly 121px, the shipped value. */
  .mk-page .mk-ecology .mk-ecology__title {
    font-size: clamp(66px, calc(10.7142857vw - 41.1428571px), 96px);
    line-height: 1.2604166667;                 /* 121 / 96 — exact at 96px */
    white-space: nowrap;
  }
}


/* ==========================================================================
   §4. D04 — THE RECOVERY RAIL IS NOT FLUSH TO THE RIGHT EDGE
   FOLD-BACK TARGET: css/_band-xl.css §1 (lane `fluid:xl`).
   ========================================================================== */

/* ⚠ CSS COMMENTS DO NOT NEST, AND THIS BLOCK LEARNED IT THE EXPENSIVE WAY.
   The first revision quoted _band-xl.css's declaration inside this prose block
   WITH ITS TRAILING TRAILING-COMMENT ATTACHED. That inner close-marker ended the OUTER
   comment early; everything after it was parsed as CSS, and the parser ate this
   entire `@media (min-width: 1441px)` block while recovering. The sheet still
   loaded, `document.styleSheets` still listed it, §1-§3 still worked — and §4
   was simply ABSENT from the CSSOM. The page measured EXACTLY as if this fix
   had never been written: gapRight 36 at 1512, 144 at 1728, 240 at 1920.
   That is why D04 is verified by reading `getComputedStyle().paddingRight` and
   by enumerating the rules the element `matches()` (review/rhythm/probe-pr.js),
   not by confirming the declaration is in the file. A rule you can grep is not
   a rule the browser has. Never write a comment OPEN-MARKER inside a CSS comment; use `--` prose.
   And note that the first two attempts to write this very warning BOTH failed:
   the first quoted the markers it was warning about, and the second forgot its
   own close marker. Three parse failures, three identical symptoms, one lesson:
   THE ONLY EVIDENCE THAT A CSS RULE EXISTS IS THAT THE BROWSER APPLIES IT.
   review/rhythm/check-css.py now asserts marker balance on this file. */

/* "Recovery 'Step 1 of 5 / recover in a safe environment' is not flush to the
    right edge of the browser; stray right margin/padding. Correct at reduced
    width, wrong at hers."

   ROOT CAUSE, MEASURED, AND IT IS NOT IN A RECOVERY SECTION'S OWN FILE.
   `css/_band-xl.css` §1 fixes a real defect above 1441: the five recovery rails
   kept their ink 120px from the VIEWPORT edge while the other twenty sections
   moved their ink out to `(vw-1440)/2 + 120`.  Its fix is

       padding-inline: var(--mk-xl-inset);        -- i.e. (vw - 1440) / 2

   applied to the row.  `padding-inline` is BOTH sides.  The left half is
   correct and is kept.  The right half pulls the media column off the viewport
   edge by the same amount, and the media column is the thing D23 says must
   bleed:

       09-recovery-42.css, MK-RPLAN §1, quoting FT-20260817 D23 —
       "Image must bleed past margin/padding on the right; left content half,
        right image edge-to-edge vertically and half-container horizontally."

   MEASURED right-edge gap on `.mk-recovery-42__images`
   (`review/rhythm/before-d01-d02-d04.json`):

       1280 ->   0px    correct   (below the 1441 band edge; the rule is inert)
       1512 ->  36px    WRONG     = (1512 - 1440) / 2
       1728 -> 144px    WRONG     = (1728 - 1440) / 2

   Which is the founder's sentence exactly: "correct at reduced width, wrong at
   hers".  It also dates her viewport for us — the defect only exists above
   1441px, so she is reviewing at 1512 or wider.

   WHY THE BAND-XL LANE COULD NOT SEE IT.  Its own verification table
   (`_band-xl.css` §1 header) records "rail ink-left" and "media width" and
   nothing else.  Both are correct under its fix.  The quantity that broke — the
   media column's RIGHT EDGE — is not in the table, and a right edge is not
   recoverable from a left edge plus a width unless you also know the padding
   you just added.  `founder-trace/PREDICATES.md:1993` already states the test
   this needed ("The element's right edge equals the viewport's, to the pixel,
   at 1280 / 1440 / 1512 / 1920"); it was written for D11 and never applied to
   these five.

   WHY THE OVERRIDE LIVES HERE RATHER THAN AS AN EDIT TO _band-xl.css.
   One writer per artifact: `_band-xl.css` is another lane's file and
   `r3:recovery-plan` is concurrently rewriting 08-13.  `padding-left` is
   restated at the same specificity so this block is a complete statement of the
   intended geometry rather than a subtraction from someone else's, and the two
   selector lists are kept character-identical so the fold-back is a one-line
   substitution of `padding-inline` for the pair below. */

@media (min-width: 1441px) {

  /* ONE PROPERTY, AND THAT NARROWING IS DELIBERATE.
     An earlier revision also restated `padding-left: var(--mk-xl-inset)` here,
     to keep _band-xl.css §1's correct left-gutter fix while cancelling its
     incorrect right half. While this lane was verifying that,
     `r3:recovery-plan` landed a BETTER mechanism at id specificity
     (09-recovery-42.css R3-A): `padding-inline: 0` on the same five rows, with
     the page gutter moved onto the RAIL's own padding via
     `--mk-rplan-gutter: calc(var(--mk-page-x) + max(0px, (100vw - 1440px)/2))`.
     That bleeds the row on BOTH edges and re-derives the ink inset where it
     belongs, which is strictly better than insetting the row and then undoing
     half of it.

     So the `padding-left` restatement was removed rather than left to disagree
     with theirs at a lower specificity. What remains is a single assertion of
     the one quantity D04 names — the RIGHT edge — which their rule and this one
     agree on exactly. It is therefore redundant today by construction and can
     never be a conflict; it exists so that removing either lane's rule leaves
     the founder-reported defect fixed rather than silently restored. */
  .mk-xl-rail,
  [data-mk-slug="09-recovery-42"] .mk-recovery-42__row,
  [data-mk-slug="10-recovery-41"],
  [data-mk-slug="11-recovery-43"] .mk-recovery-43__split,
  [data-mk-slug="12-recovery-44"],
  [data-mk-slug="13-recovery-45"] > .wpb_row > .row_col_wrap_12 {
    padding-right: 0;
  }
}