/**
 * Harvest — Messages / toasts (C9).
 *
 * Styles Magento core `.message` banners (success/error/notice/warning emitted
 * by the framework after cart/checkout/account actions) AND the theme's own
 * transient `.hrv-toast` stack. State colours map to the shared --hrv-success/
 * error/warning tokens so a "success" always reads the same across the theme.
 */

/* ---------- Inline banner (core .message + .hrv-message) ---------- */
/* THE PAGE GUTTER WAS APPLYING TWICE. Two nested visible elements carry this class -
   `div.page.messages` and a `div.messages` inside it - so `padding-inline` landed on both, on
   top of the 24px `.page-main` already provides. On T23 that made the error banner 352px wide
   against a 480px card: 128px narrower at 1440, 64px at 375, i.e. 27% - measured, with the
   nested override injected and removed as a control (352 -> 416 -> 352).

   Register #42 recorded this symptom on Login and blamed "core chrome shared by every route,
   not touched by any selector". That diagnosis was FALSE: `styles-m.css` contributes nothing to
   `.messages`, and the only source of horizontal padding is this rule. It was patchable all
   along, and it was registered instead. */
.messages .messages {
  padding-inline: 0;
  max-width: none;
}

/* AND THE OUTER HALF, WHICH WAS DECLARED AS A RESIDUE AND IS NOT ONE. `.page.messages` is a
   DIRECT CHILD of `main.page-main`, which already supplies the page gutter - so this is the same
   duplicate one level up. S4 measured the fix across eleven distinct routes at two viewports: it gains
   exactly 64px at 1440 and 32px at 375 on every one, aligns the banner with `.page-main`'s content
   box on every one, and on the T23 route aligns it EXACTLY with the card (480@480, 327@24). Control
   held on every route.
   Calling the outer gutter inherent framed as unavoidable something the measurement says is one
   line away, which is the same shape as register #42's original false diagnosis.
   IT DOES NOT REACH THE AUTHENTICATION-POPUP BANNER. That element sits at
   `#authenticationPopup > .block-authentication > .block.block-customer-login > .messages`, is NOT
   a child of `.page-main`, and so the selector above never matches it: it computes
   `padding-inline: 32px`.

   THIS PARAGRAPH HAS NOW BEEN WRONG TWICE, IN OPPOSITE DIRECTIONS, AND THE SECOND VERSION COMMITTED
   THE EXACT SIN IT WAS WRITTEN TO CORRECT. Version one claimed the fix swept the popup up and cited
   996-in-1060 as proof. Version two said it did NOT sweep it up and cited THE SAME 996-in-1060 as
   proof of that. S8 measured the element: on all twelve routes as shipped it is 0x0 with an empty
   `getClientRects()`, hidden by `.block-authentication`. 996-in-1060 is a reading of NEITHER state -
   it appears only on `/customer/account/login/` with an ancestor forced visible, and even then it
   varies with the column (route A forced open is 416 in 480).
   So: the defect is real, the diagnosis is right, and both quantities were invented. What is
   measured is that the padding computes, that the element does not render until the popup opens,
   and that when forced open it inherits the double gutter.

   Left unfixed rather than papered over - it is invisible until the popup opens, which is the
   honest reason, not a route count. Recorded on register #42.

   FOUR MORE SURVIVORS WERE LISTED HERE WITH FIGURES AND ARE NOW MARKED UNCONFIRMED: on `/checkout/`
   `div.checkout-container > .messages`, `.payment-method-content > .messages` and
   `.payment-option-content > .messages`; and one on the success page. S8 could not reach any of
   them - `/checkout/` 302s to the cart on an empty basket, and `.payment-option-content` is a
   collapsed accordion that is `display:none` by default, i.e. structurally at risk of the identical
   zero-box error this paragraph just made twice.
   VERIFIED SINCE: `/checkout/onepage/success/` was unreachable when this was written (empty quote),
   so the outcome was stated as expected. S7 then placed a REAL GUEST ORDER to reach it and measured
   `padding-inline: 0`, `max-width: 720px`, content box x=360 w=720 - the banner goes 656 -> 720, into
   alignment with its own column, exactly as predicted. */
.page-main > .messages {
  padding-inline: 0;
}

.messages { max-width: var(--hrv-container); margin-inline: auto; padding-inline: var(--hrv-page-pad); }
.message,
.hrv-message {
  display: flex;
  align-items: center;
  gap: 12px;
  padding: 13px 18px;
  margin: 10px 0;
  font-size: 13.5px;
  border: 1px solid;
  border-radius: var(--hrv-radius-md);
}
.message > *:first-child::before { margin: 0 8px 0 0; }

.message.success,
.hrv-message--success {
  border-color: var(--hrv-success);
  color: var(--hrv-success);
  background: color-mix(in oklab, var(--hrv-success) 8%, var(--hrv-surface));
}
.message.error,
.hrv-message--error {
  border-color: var(--hrv-error);
  color: var(--hrv-error);
  background: color-mix(in oklab, var(--hrv-error) 8%, var(--hrv-surface));
}
.message.warning,
.hrv-message--warning {
  border-color: var(--hrv-warning);
  color: var(--hrv-warning);
  background: color-mix(in oklab, var(--hrv-warning) 8%, var(--hrv-surface));
}
.message.notice,
.message.info,
.hrv-message--info {
  border-color: var(--hrv-accent);
  color: var(--hrv-accent);
  background: var(--hrv-accent-tint);
}
/* THIS RULE HAS BEEN DEAD SINCE IT WAS WRITTEN, ON EVERY MESSAGE VARIANT IN THE THEME.
   `.message a` is (0,1,1); Blank's compiled bundle declares `#1979c3` for EIGHT message-link
   selectors across SEVEN rule blocks - two of them GROUPED on one line - at (0,2,1), and (0,3,1)
   for the three `.global` ones. Every one outranks it, so every link inside a Magento message has
   been rendering Luma blue while this file said `inherit`. (SCOPE NOTE, added after the S8
   gate: what follows fixes the BASE state only. The hover/focus/active states were a
   separate omission and are handled in their own block below - do not read this paragraph
   as covering them. The first version of it claimed the fix closed this for "every link
   inside a Magento message", which was an overstatement by exactly one interaction.) Read out of the shipped bundle rather
   than recalled, and transcribed in full this time:

     .message.info a{color:#1979c3      .message.notice a{color:#1979c3
     .message.error a{color:#1979c3     .message.success a{color:#1979c3
     .message.warning a{color:#1979c3   .message.global.demo a{color:#1979c3
     .message.global.noscript a,.message.global.cookie a{color:#1979c3

   THE FIRST VERSION OF THIS BLOCK SAID "SEVEN, ONCE PER VARIANT" AND SHIPPED A LIST OF SEVEN,
   MISSING `.message.global.noscript a`. The extract transcribed only the SECOND HALF of that
   grouped line, so the count and the list agreed with each other and with nothing else - and the
   one claim an explicit list exists to support, that it can be diffed against Blank's, was the
   claim that failed. Live impact is small: that markup sits inside `<noscript>`, so it is not an
   element while JS runs. It is real for a JS-disabled shopper, and it is exactly the defect an
   unverified "exactly Blank's list" invites. Found by the S4 gate reading the bundle.

   FOUND BY UNHIDING SOMETHING, NOT BY AUDITING. basil-T7 stopped `_search.css` suppressing the
   zero-result notice when it carries a "Did you mean" list; the two suggestion links came back
   `rgb(25, 121, 195)`. A census then found a SECOND live instance that owed nothing to that
   change - `.message.error a` "Modify your search." on /catalogsearch/advanced/result/, blue on
   the storefront today. So this is a shared-component defect that a page-scoped fix would have
   left everywhere else, which is why it is fixed here and not in `pages/_search.css`.

   The variants are matched EXPLICITLY rather than with a higher-specificity trick, because the
   selector list is exactly Blank's and can be diffed against it. At equal (0,2,1) the theme
   wins on source order - verified on this build rather than assumed: `_base.css`'s `a` at
   (0,0,1) already beats Blank's `a, .alink` on the same page.

   `inherit` is the theme's OWN pre-existing intent, not a new colour decision: the link takes
   its message's text colour, which this file already sets three rules above. Measured after the
   fix on the two live instances (basil, 1440): notice links and error links both take their
   message's colour, and the underline is kept so the link stays distinguishable without relying
   on hue alone. */
.message.info a,
.message.error a,
.message.warning a,
.message.notice a,
.message.success a,
/* `noscript` BEFORE `cookie`, because that is Blank's order on the grouped line above, and
   diffability against Blank is the entire reason this list is written out rather than replaced
   by a higher-specificity trick. Copilot's review of the fix: a list that is auditable only if
   you sort it first is not auditable. */
.message.global.noscript a,
.message.global.cookie a,
.message.global.demo a,
.message a,
.hrv-message a { color: inherit; text-decoration: underline; }

/* THE BASE STATE WAS NOT THE WHOLE DEFECT. This theme shipped ZERO interaction rules of ANY
   kind - measured, not estimated: a grep for `message...a:(hover|focus|active)` over the
   previous revision returns 0, and the same grep over this one returns 30. So every message
   link reverted to Luma blue the moment a pointer touched it - the same defect the block above
   fixes, one interaction away, on all seven variants. A fix verified only in its resting state
   is a fix verified on the happy path.

   BLANK'S INTERACTION RULES ARE NOT UNIFORM, AND THE FIRST VERSION OF THIS PARAGRAPH SAID THEY
   WERE. It read "FOURTEEN hover/active declarations of `#006bb4` at (0,3,1)" and, below, "all
   `#006bb4`". Both false, and false in the same shape as the defect this block replaced: a
   generalisation across a list whose three `.global` members differ. It also contradicted the
   corrected paragraph fifty lines above, which makes exactly that `.global` distinction for the
   base state and then dropped it here. Audited from the served CSSOM with a self-tested
   specificity calculator (`a`->0,0,1; `.message a`->0,1,1; `.message.notice a`->0,2,1;
   `.message.notice a:hover`->0,3,1; `.message.global.noscript a:hover`->0,4,1):

     14 rule blocks / 16 selectors
       colour:      12 blocks `#006bb4`  ·  2 blocks `#ff5501`
                    (`.message.global.{noscript,cookie,demo} a:active` are the orange three)
       specificity: 10 selectors (0,3,1)  ·  6 selectors (0,4,1)

   The conclusion survives the correction but the reasoning as first written did not reach it:
   "at equal (0,3,1) the theme wins on source order" covers only ten of the sixteen. The theme's
   own `.global` interaction selectors are likewise (0,4,1), so it is a tie decided by source
   order at BOTH weights - which is why the observed readings below come out right.

   OBSERVED, NOT DERIVED - AND THE FIRST VERSION OF THIS NOTE GAVE UP TOO EARLY. It said the
   behaviour could not be watched because Chrome will not report hover computed styles and the
   render rig exposes no `Input.dispatchMouseEvent`. Both true, and both a limit of the
   instrument being held rather than of the task. CDP's `CSS.forcePseudoState` makes the engine
   resolve the state itself; driven from a second CDP client attached to the same browser while
   a probe held the page open, every state on both live message links reads `rgb(76,122,63)` -
   the message's own text colour - with no Luma blue anywhere.

   TWO CONTROLS, because a forcing API that silently does nothing reads exactly like a working
   fix. (1) Mechanism: `.nav-sections a` moves under forced hover. The first candidate tried,
   `.action.primary`, did NOT move - a single-candidate control would have declared the
   instrument dead and voided every reading. (2) Counterfactual on the shipped artefact:
   deleting this block from the live CSSOM (1 of 18 rules - one block carries all 30 selectors)
   sends both links to `rgb(0,107,180)` = `#006bb4`. So the pre-fix behaviour is reproduced, and
   this block is proven to be what prevents it.

   Same explicit-list approach as the block above, for the same reason: at equal (0,3,1) the
   theme wins on source order, and the list stays diffable against Blank's. `currentColor` rather
   than `inherit` so a hovered link keeps its own message's text colour. */
.message.info a:hover,
.message.info a:focus,
.message.info a:active,
.message.error a:hover,
.message.error a:focus,
.message.error a:active,
.message.warning a:hover,
.message.warning a:focus,
.message.warning a:active,
.message.notice a:hover,
.message.notice a:focus,
.message.notice a:active,
.message.success a:hover,
.message.success a:focus,
.message.success a:active,
.message.global.noscript a:hover,
.message.global.noscript a:focus,
.message.global.noscript a:active,
.message.global.cookie a:hover,
.message.global.cookie a:focus,
.message.global.cookie a:active,
.message.global.demo a:hover,
.message.global.demo a:focus,
.message.global.demo a:active,
.message a:hover,
.message a:focus,
.message a:active,
.hrv-message a:hover,
.hrv-message a:focus,
.hrv-message a:active { color: currentColor; text-decoration: underline; }

/* ---------- Toast stack (theme-authored, transient) ---------- */
.hrv-toast-stack {
  position: fixed;
  top: 24px;
  right: 24px;
  z-index: 60;
  display: flex;
  flex-direction: column;
  gap: 10px;
  max-width: 340px;
}
.hrv-toast {
  display: flex;
  align-items: flex-start;
  gap: 10px;
  padding: 14px 16px;
  background: var(--hrv-surface);
  border: 1px solid var(--hrv-border-strong);
  border-left: 3px solid var(--hrv-text);
  border-radius: var(--hrv-radius-md);
  font-size: 13px;
  box-shadow: var(--hrv-shadow-card);
}
.hrv-toast--success { border-left-color: var(--hrv-success); }
.hrv-toast--error { border-left-color: var(--hrv-error); }
.hrv-toast--warning { border-left-color: var(--hrv-warning); }
.hrv-toast-body { flex: 1; color: var(--hrv-text); }
.hrv-toast-close {
  background: none;
  border: none;
  color: var(--hrv-text-subtle);
  cursor: pointer;
  font: inherit;
  font-size: 16px;
  width: 24px;
  height: 24px;
  flex-shrink: 0;
  display: grid;
  place-items: center;
}

@media (max-width: 767px) {
  .message,
  .hrv-message { flex-wrap: wrap; }
  .hrv-toast-stack { left: 16px; right: 16px; top: 16px; max-width: none; }
}

/* A link inside a message is an ACTION, not prose: "Modify your search." on the advanced-search
   results measured 268x31. Messages appear all over the store, so this is deliberately set on
   the shared class rather than on that one page - the same 3.18 reasoning as the breadcrumbs,
   which turned out to be one small link on thirty-five pages. Height only: these links are
   already wide, and min-width would stretch a short one across the message box. */
@media (max-width: 767px) {
  .message a {
    display: inline-flex;
    align-items: center;
    min-height: 44px;
  }
}