/* ─── Badges ─────────────────────────────────────────────────────── */
.hzo-badge {
    display: inline-flex;
    align-items: center;
    line-height: var(--lh-none);
    padding: 6px 11px;
    border-radius: var(--badge-radius, var(--radius-full));
    font-size: var(--fs-50);
    font-weight: var(--badge-weight, var(--fw-600, 600));
    letter-spacing: 0.03em;
    text-transform: uppercase;
    background: var(--bg-alt);
    color: var(--text-body);
}
.hzo-badge--primary   { background: var(--brand); color: var(--text-on-brand); }
.hzo-badge--secondary { background: var(--accent); color: var(--text-on-accent); }
/* State variants — PF-043.
   These four used to hardcode `color: #fff` on the shared semantic state fill,
   with no on-state ink token able to co-vary with a retint. Badge text is
   --fs-50 (12px), i.e. NORMAL text, so WCAG AA wants 4.5:1. White on fill:

       --info     #2563EB   5.17:1   pass
       --error    #DC2626   4.83:1   pass, thin
       --warning  #D97706   3.19:1   FAIL
       --success  #16A34A   3.30:1   FAIL

   These are engine tokens, not recipe-derived, so the two failures were
   identical on every install — not a per-client palette problem. And the
   failure was one-way: a client who retinted --success/--warning LIGHTER made
   it worse, because the ink stayed white.

   Fixed by giving the badge its own fill + ink tokens rather than by moving
   --success / --warning themselves. Those two are also consumed by alert and
   callout, where they are already safe (pale -bg fill + dark -ink text), and
   darkening the shared token to fix a badge would have shifted the semantic hue
   everywhere it is used. Defaults are the two darkened fills PF-043 proposed:

       --badge-success-bg  #15803D   white on it = 5.02:1   pass
       --badge-warning-bg  #B45309   white on it = 5.02:1   pass

   error/info route through the same token names at their existing values, so a
   client retinting any state has ONE place to do it and an ink token to go with
   it. Anyone overriding a fill LIGHTER must also set --badge-on-state dark.

   The tokens are declared here as var() fallbacks rather than in tokens.css's
   Badge block (which today holds only --badge-radius / --badge-weight). Folding
   them in there alongside the other component tokens is the tidier end state and
   is a safe follow-up — the fallbacks keep working either way. */
.hzo-badge--success   { background: var(--badge-success-bg, #15803D); color: var(--badge-on-state, #fff); }
.hzo-badge--warning   { background: var(--badge-warning-bg, #B45309); color: var(--badge-on-state, #fff); }
.hzo-badge--error     { background: var(--badge-error-bg, var(--error)); color: var(--badge-on-state, #fff); }
.hzo-badge--info      { background: var(--badge-info-bg, var(--color-info)); color: var(--badge-on-state, #fff); }
.hzo-badge--outline   { background: transparent; color: var(--brand-text); border: 1px solid var(--brand-text); }
/* Sale — promo attention badge. Reuses the accent (the system's `--emphasis`
   attention colour) so it stands apart from the stock states; no new token. Always
   pair with the word "Sale" so the meaning is never carried by colour alone.
   Stock states compose existing variants: in-stock = --success, low-stock =
   --warning, out-of-stock = the base (neutral) badge — unavailability is a state,
   not an error, so red (--error) is reserved for genuine errors. */
.hzo-badge--sale      { background: var(--accent); color: var(--text-on-accent); }