/**
 * ERPAL ONE — TOP BAR (NAV-3 + NAV-2).
 * Logo · tool tabs · search merged with [+] quick-create · theme toggle ·
 * avatar menu. Colors come exclusively from css/erpal-tokens.css custom
 * properties — no hardcoded colors in this file.
 */

/* The base .erpal-topbar (sticky, height, surface) is styled in app.css.
   Tighten the gap — this bar carries more content than the old one. */

/* HORIZONTAL-OVERFLOW CONTAINMENT WITHOUT CLIPPING (standard §6.6).
   ⚠️ DO NOT PUT AN OVERFLOW VALUE ON `.erpal-topbar`. `overflow-x: auto`
   shipped here in the d-2026-08-03-003 fold (1.0.2) and broke the avatar menu
   on every tenant, because per CSS Overflow §3 a non-`visible` value on ONE
   axis forces the OTHER axis from `visible` to `auto` -- so the bar silently
   became a scroll container, and a scroll container clips. Three things open
   OUT of this bar on purpose, all `.erpal-dropdown` at `top: calc(100% + 6px)`:
   the avatar/user menu, the [+] quick-create menu, and the tool-tab sub-menus.
   MEASURED on the live LD hub 2026-08-08 before this fix, at 1920/390/360: the
   menu was in the DOM, `display: block`, 185×100px, extending 96px below the
   bar -- and `document.elementFromPoint` at its centre AND at its last item
   ("Sign out") returned `MAIN.erpal-content` / `H1.title`, i.e. the page
   underneath. Log out and the theme toggle were unreachable; ~3px of sliver was
   all that painted. (The tool-tab menus escaped only because
   css/erpal-tidymenu.css re-positions them `fixed` -- a workaround for exactly
   this bug, not a design.)
   It was also not earning its keep: `overflow-x: auto` makes the TOPBAR scroll,
   it never stopped the DOCUMENT from widening, and the hub still scrolled
   sideways at 360px with it in place. What actually made the bar refuse to
   shrink is below: flex items default to `min-width: auto`, so every child held
   a min-content floor (measured: 401px of content in a 330px box at 360px, and
   the bar quietly scrolled its own logo out of view when the avatar was
   focused). Letting the children shrink is the containment. */
.erpal-topbar {
  gap: 12px;
  /* not 100vw: 100vw counts the vertical scrollbar gutter, so on a scrolling
     page it is ~15px WIDER than the space the bar actually has. */
  max-width: 100%;
  overflow: visible;   /* both axes, explicitly — see the note above */
  box-sizing: border-box;
  min-width: 0;
}
/* The containment that `overflow-x: auto` was standing in for. */
.erpal-topbar > * { min-width: 0; }

/* ---- nav toggle (hide / show the rail) ----
   NEW AT ≥769px IN 1.2.3, AND THAT IS THE RISK IN THIS RELEASE. A control the
   bar did not have to carry before now costs it 34px plus one 12px gap on the
   LEFT, and the left is not where this bar has slack. Worse, the expanded
   state is the tight one: the top bar lives inside .erpal-main, so while the
   rail is out the bar's box is (viewport − 248px) — at Troy's 1024px tablet
   that is 776px, the exact width 1.2.0 overflowed at and 1.2.1 was cut to fix
   (commit 6c416912c). Collapsing gives the 248px back, so the state that
   RELIEVES the pressure is the one nobody is in on first load.

   Three things keep this inside the budget, and all three are shrink-only —
   nothing here grows, and nothing becomes a scroll container:

     1. `flex: 0 0 auto` on a fixed 34px box. The toggle never grows into the
        search's space and never shrinks below its own tap target, so it cannot
        become the invisible-but-present button of the 1.2.0 lesson.
     2. It spends the bar's own padding rather than new width: the 24px left
        pad is pulled to 10px while the control is there, which buys back 14px
        of the 46px before anything else has to give.
     3. The two elastic members absorb the rest — .erpal-searchplus
        (flex: 1 1 240px, min-width: 0 on box AND input since 1.2.1) and
        .erpal-tooltabs (flex: 0 1 auto, min-width: 0, its own overflow-x).

   MEASURED, not reasoned: 390 / 768 / 820 / 1024 / 1280 / 1920, expanded and
   collapsed, document scrollWidth <= clientWidth at every one, and the toggle
   hit-tested with elementFromPoint at its own centre at every one. The
   measurement is the point — 1.2.0 had correct markup, correct CSS and a
   passing render check, and the button still could not be clicked. */
.erpal-topbar__navtoggle {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  flex: 0 0 auto;
  width: 34px;
  /* 40px is the floor the hub button states; the bar is 56px so this fits. */
  min-height: 40px;
  padding: 0;
  border-radius: 8px;
  color: var(--erpal-muted);
  transition: color .12s, background .12s;
}
.erpal-topbar__navtoggle:hover { color: var(--erpal-text); background: var(--erpal-hover); }
.erpal-topbar__navtoggle:focus-visible {
  outline: 2px solid var(--erpal-accent);
  outline-offset: 2px;
}
/* An inline <svg> has NO intrinsic box (the 1.0.5 lesson) — without these two
   lines the glyph is a zero-size nothing and the control is a blank 34px hole. */
.erpal-topbar__navicon { width: 18px; height: 18px; flex: 0 0 auto; }
/* The collapsed rail is what the control is offering to bring back, so it
   reads as the ACTIVE state rather than the resting one. */
html[data-sidenav="collapsed"] .erpal-topbar__navtoggle { color: var(--erpal-accent); }
/* Point 2 above: the toggle is paid for out of the bar's own left padding. */
.erpal-topbar { padding-left: 10px; }

/* ---- logo ---- */
.erpal-topbar__logo {
  display: flex; align-items: center; gap: 7px;
  text-decoration: none; color: var(--erpal-text);
  font-weight: 800; font-size: 1.02rem; letter-spacing: .4px;
  flex: 0 0 auto;
}
.erpal-topbar__logomark { color: var(--erpal-accent); font-size: 1.15rem; }

/* ---- tool tabs ---- */
.erpal-tooltabs {
  display: flex; align-items: stretch; gap: 2px;
  height: 100%; flex: 0 1 auto; min-width: 0;
  overflow-x: auto; scrollbar-width: none;
}
.erpal-tooltabs::-webkit-scrollbar { display: none; }
.erpal-tooltab {
  display: inline-flex; align-items: center;
  padding: 0 13px;
  color: var(--erpal-muted); text-decoration: none;
  font-size: .9rem; font-weight: 600; white-space: nowrap;
  border-bottom: 3px solid transparent;
  border-top: 3px solid transparent; /* keeps the label vertically centered */
  transition: color .12s, border-color .12s, background .12s;
}
.erpal-tooltab:hover { color: var(--erpal-text); background: var(--erpal-hover-soft); }
.erpal-tooltab.is-active {
  color: var(--erpal-accent);
  border-bottom-color: var(--erpal-accent);
}

/* ---- search merged with [+] ---- */
/* The search is the bar's ELASTIC member: it takes the slack at a wide viewport
   and gives it back at a narrow one. `min-width: 160px` was a hard floor that
   could not give it back — 160px of search is 160px the document has to find
   somewhere, and at 360px there is no somewhere. A flex-basis says the same
   thing as a preference instead of as a floor. */
.erpal-searchplus {
  display: flex; align-items: center;
  flex: 1 1 240px; max-width: 480px; min-width: 0;
  margin-left: auto;
}
.erpal-searchplus .erpal-search {
  flex: 1 1 auto; max-width: none;
  border-radius: 8px 0 0 8px; border-right: 0;
}
.erpal-qc { position: relative; flex: 0 0 auto; }
.erpal-qc__btn {
  display: inline-flex; align-items: center; justify-content: center;
  width: 38px; height: 38px;
  border: 1px solid var(--erpal-accent-fill); border-radius: 0 8px 8px 0;
  /* FILLED CONTROL -> the fill pair, not the accent pair (d-2026-09-02-048
     class 1): white on Night's lifted #5b9bff measures 2.77:1. */
  background: var(--erpal-accent-fill); color: var(--erpal-on-accent-fill);
  font-size: 1.35rem; font-weight: 700; line-height: 1; cursor: pointer;
}
.erpal-qc__btn:hover { background: var(--erpal-accent-dark); border-color: var(--erpal-accent-dark); }

/* ---- shared dropdown ---- */
.erpal-dropdown {
  position: absolute; top: calc(100% + 6px); right: 0; z-index: 60;
  min-width: 185px;
  background: var(--erpal-surface);
  border: 1px solid var(--erpal-border);
  border-radius: var(--erpal-radius);
  box-shadow: var(--erpal-shadow-lg);
  padding: 6px;
}
/* ⛔ `hidden` IS THE OFF SWITCH FOR EVERY ONE OF THESE MENUS, AND AN AUTHOR
   `display` OUTRANKS IT. The UA stylesheet's `[hidden] { display: none }` lives
   in the USER-AGENT origin, so ANY author rule that sets `display` on the same
   element beats it — no !important, no specificity contest, just origin order.
   The rule above escapes that only because it never sets `display`, which is
   luck rather than design: the moment a descendant menu needs a layout mode,
   its off switch stops working silently and nothing in the JS looks wrong.

   That is exactly what happened to `.erpal-tbmore__menu` (2026-08-26 →
   2026-09-01). MEASURED on the live hub at 390px, logged in, on /fleet: the
   attribute read `hidden`, the computed display read `flex`, the element
   painted a real 190x170 box at (175, 51) over the page content, and
   `document.elementFromPoint` at its own centre returned the Tour BUTTON
   inside it — in ALL FOUR states (first paint, after tapping "⋯", after an
   outside click, with the nav drawer open). js/erpal-layout.js toggles the
   attribute correctly and always did; the attribute simply had no consequence,
   so the flyout sat open over Fleet Health and the "⋯" control read as dead.
   Troy hit this in the installed PWA on his phone.

   The guard is written for the SHARED class, not for the one menu that broke,
   so the next dropdown that needs a `display` cannot reintroduce it. It is the
   one place in this stylesheet where !important is correct: this is not a
   style preference, it is a visibility invariant that every rule below must
   lose to. */
.erpal-dropdown[hidden] { display: none !important; }
.erpal-dropdown__item {
  display: block; padding: 8px 12px;
  border-radius: 6px;
  color: var(--erpal-text); text-decoration: none;
  font-size: .88rem; font-weight: 500; white-space: nowrap;
}
.erpal-dropdown__item:hover,
.erpal-dropdown__item:focus {
  background: var(--erpal-accent-soft); color: var(--erpal-accent); outline: 0;
}

/* ---- back to the Lucky Duck Hub ----
   Same pill geometry as the theme toggle beside it, so the far-right cluster
   reads as one row of controls rather than a button someone bolted on. It is
   quiet by default (muted text, surface fill) and only takes the accent on
   hover: this is an exit, not a call to action, and it must not compete with
   the CRM's own navigation.

   1.2.2 — THE LABEL SHORTENS, IT NEVER DISAPPEARS. 1.2.1's collapse (below)
   left the glyph carrying the meaning alone, and MEASURED on the live hub the
   result was a 34x41 pill containing one "←" at 390px and at 768px, with the
   label clipped to 1px. On a phone that is a dash, not a control: Troy went
   looking for the way back to /hub and could not find it. An icon-only control
   is only self-evident when its icon is, and a left arrow next to a search box
   is not — so under 1200px the full name is replaced by the three-character
   "Hub" rather than by nothing, and the glyph becomes the sprite's 2x2 grid,
   which is what /hub actually looks like.

   Three characters is not what runs a topbar out of room. MEASURED after this
   change (390 / 768 / 1024 / 1366): the bar's content still fits its box at
   every width, because .erpal-searchplus is `flex: 1 1 …; min-width: 0` and
   gives the width back — the same shrink pass 1.1.3 started and 1.2.1
   finished. Nothing here sets a floor, nothing gains a fixed width, and no
   element becomes a scroll container.

   1200px, NOT the 900px this shipped with, and the difference was MEASURED on
   a 1024px-wide tablet portrait viewport rather than guessed: with the label
   showing, the button is 98px wide, the right cluster's content becomes 209px
   inside a 188px box, its left edge moves from ~896px to 796px, and it lands
   underneath the quick-create [+] control — document.elementFromPoint at the
   button's own centre returned BUTTON.erpal-qc__btn and Playwright could not
   click it. A control that renders and cannot be clicked is worse than no
   control. See the searchplus shrink fix below for the other half. */
.erpal-topbar__hub {
  display: inline-flex; align-items: center; gap: 6px;
  border: 1px solid var(--erpal-border); border-radius: 999px;
  background: var(--erpal-surface); color: var(--erpal-muted);
  padding: 6px 12px; font-size: .8rem; font-weight: 600;
  text-decoration: none; white-space: nowrap;
  /* A phone target, stated rather than inherited from whatever the glyph's
     line box happened to measure. min-height only — it can still grow, and it
     never sets a WIDTH floor, so the shrink behaviour below is untouched. */
  min-height: 40px;
}
.erpal-topbar__hub:hover,
.erpal-topbar__hub:focus {
  color: var(--erpal-accent); background: var(--erpal-accent-soft);
  border-color: var(--erpal-accent); outline: 0;
}
/* The grid glyph. Sized like the tool-tab icons (17px) so the far-right
   cluster reads as one row; `flex: 0 0 auto` because the icon is the one part
   of this control that must not shrink — the label is what gives way. */
.erpal-topbar__hubicon { width: 17px; height: 17px; flex: 0 0 auto; }
/* The cross-origin ↗ is a text glyph, not an SVG: let it size itself. */
.erpal-topbar__hubicon--out { width: auto; height: auto; font-size: .95rem; line-height: 1; }
/* The short name exists only for the collapsed state. */
.erpal-topbar__hubshort { display: none; }
@media (max-width: 1200px) {
  /* The full name goes sr-only rather than away: the accessible name stays
     "Lucky Duck Hub" for a screen reader (and aria-label on the anchor says
     the same), while the eye gets the three characters that fit. */
  .erpal-topbar__hublabel { position: absolute; width: 1px; height: 1px; overflow: hidden; clip: rect(0 0 0 0); white-space: nowrap; }
  .erpal-topbar__hubshort { display: inline; }
  .erpal-topbar__hub { padding: 6px 10px; }
}

/* ---- FLEET HEALTH: the phone's way to /fleet (Troy, 2026-09-01) ----

   /fleet had NO entry point on a phone. MEASURED on the live hub at 390px,
   logged in as an admin seat: `a[href^="/fleet"]` returned ZERO nodes on the
   whole page — the bottom app bar is full (Leads · Calendar · [+] · Routes ·
   Dashboard, five slots at 78px each and no room for a sixth at 390px), the
   tool tabs are `display: none` below 768px, and the CRM rail is behind the
   burger, ~35 icon boxes and ~2,200px of scrolling above the Operations group.
   The board got its mobile card layout on 8/31 and could not be reached to
   see it.

   TWO entries ship, and they are deliberately different answers:

     • the CRM rail — fleet_watch.links.menu.yml puts "Fleet Health" in the
       Operations group beside DuckBot Deployments and Service Instances. That
       is its CANONICAL home, it is where someone browsing the CRM will look,
       and it is a real menu link so the router's own access check hides it
       from a seat without `view fleet dashboard`.

     • THIS control — the one that answers Troy's actual complaint, because
       one tap on the "⋯" already at the top-right of every page opens the
       menu with Fleet in it. js/erpal-layout.js does the move for free: any
       child of .erpal-topbar__right that is not KEEP_INLINE relocates into
       the overflow menu at <=768px and back out above it, so this control
       needs no JavaScript of its own.

   IT IS A PHONE CONTROL ONLY, and that is the point rather than an oversight.
   At >=769px the CRM rail is a permanent layout column with the Operations
   group already expanded, so the same destination is one glance away and a
   second copy in the top bar would be clutter — in a bar whose right cluster
   has already been measured into a corner twice (the 1.1.3 shrink pass and the
   1.2.2 hub-label collapse). Displaying it only where the rail is hidden adds
   nothing to the width the desktop bar has to find.

   `display: none` is safe against the relocation: layout.js reads
   `.erpal-topbar__right`'s children, not their computed style, so this element
   is in `home` and in `movable` at every width and the restore order is
   unaffected. Hidden above 768, shown below it — where it is inside the menu,
   not the bar, so it costs the bar nothing there either. */
.erpal-topbar__fleet {
  display: none; align-items: center; gap: 6px;
  border: 1px solid var(--erpal-border); border-radius: 999px;
  background: var(--erpal-surface); color: var(--erpal-muted);
  padding: 6px 12px; font-size: .8rem; font-weight: 600;
  text-decoration: none; white-space: nowrap;
  min-height: 40px;
}
.erpal-topbar__fleet:hover,
.erpal-topbar__fleet:focus {
  color: var(--erpal-accent); background: var(--erpal-accent-soft);
  border-color: var(--erpal-accent); outline: 0;
}
.erpal-topbar__fleeticon { width: 17px; height: 17px; flex: 0 0 auto; }
@media (max-width: 768px) {
  .erpal-topbar__fleet { display: inline-flex; }
}

/* ---- the search block finishes the 1.1.3 shrink pass ----
   1.1.3 gave every topbar flex item `min-width: 0` instead of the default
   `auto` min-content floor, and it is why the bar stopped widening the
   document. The SEARCH BLOCK was missed: .erpal-searchplus is
   `flex: 1 1 240px; min-width: 0`, so the box shrinks correctly — but the
   input inside it kept `min-width: auto`, so the CONTENT did not. Measured at
   a 1024px viewport: a 175px-wide block holding 271px of content, the surplus
   painting straight out of the right-hand side and over whatever the far-right
   cluster puts there. Nothing clipped it and nothing scrolled; it simply drew
   on top, which is why it survived every previous pass — until this release
   put a button in the space it was overflowing into.

   Both declarations are SHRINK fixes, so no element gains width, nothing new
   becomes a scroll container, and nothing that fits today stops fitting. */
.erpal-searchplus { min-width: 0; }
.erpal-searchplus .erpal-search,
.erpal-searchplus input { min-width: 0; }

/* ---- theme toggle (Day / Night / Auto) ---- */
.erpal-themetoggle {
  display: inline-flex; align-items: center; gap: 6px;
  border: 1px solid var(--erpal-border); border-radius: 999px;
  background: var(--erpal-surface); color: var(--erpal-muted);
  padding: 6px 12px; font-size: .8rem; font-weight: 600; cursor: pointer;
}
.erpal-themetoggle:hover { color: var(--erpal-text); background: var(--erpal-hover); }
.erpal-themetoggle__icon { font-size: .95rem; line-height: 1; }

/* ---- far-right cluster: theme toggle + avatar ----
   THE SHRINK PASS the topbar's overflow containment was standing in for.
   `.erpal-topbar__right` is defined in app.css with `margin-left: auto` and a
   flex row of its own; what it never had was permission to give width back.
   With the default `min-width: auto` it held the min-content of a theme toggle
   plus an avatar button plus whatever the `topbar` region renders, and pushed
   the document out sideways rather than narrow itself. Now: it keeps its
   natural size while there is room (`flex: 0 1 auto` — it never GROWS and
   steals the search's space), and shrinks instead of widening the page when there is
   not. Its children shrink with it, and the display name ellipsises rather than
   set a floor of its own. */
.erpal-topbar__right { flex: 0 1 auto; min-width: 0; }
.erpal-topbar__right > * { min-width: 0; }

/* ---- avatar menu ---- */
.erpal-avatar { position: relative; min-width: 0; }
.erpal-avatar__btn {
  display: inline-flex; align-items: center; gap: 8px;
  border: 0; background: none; padding: 4px; cursor: pointer;
  color: var(--erpal-text);
}
.erpal-avatar__circle {
  display: inline-flex; align-items: center; justify-content: center;
  width: 30px; height: 30px; border-radius: 50%;
  /* FILLED CONTROL -> the fill pair, not the accent pair (d-2026-09-02-048
     class 1): white on Night's lifted #5b9bff measures 2.77:1. */
  background: var(--erpal-accent-fill); color: var(--erpal-on-accent-fill);
  font-size: .85rem; font-weight: 700;
}
.erpal-avatar__circle { flex: 0 0 auto; }
.erpal-avatar__name {
  font-weight: 600; font-size: .88rem;
  /* shrink-then-ellipsis, never a min-content floor on the whole bar */
  min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap;
}
.erpal-avatar__caret { color: var(--erpal-muted); font-size: .7rem; flex: 0 0 auto; }

/* ---- 1.2.4: THE BAR OVERFLOWED AT 820 AND 1180, AND IT DID SO BEFORE 1.2.3 ----
   Measured on the live hub at /organization/1 immediately after 1.2.3 shipped:
   document scrollWidth 824 in an 805px viewport, and 1183 in 1165. Reverting
   the whole nav toggle in-page (display: none + the old 24px pad restored) left
   821 and 1178 — so the defect is PRE-EXISTING, and the toggle was adding 3px
   and 5px to it. Both facts mattered: it is not this release's bug, and this
   release must not leave it worse than it found it. The clean widths are
   unaffected throughout — 390, 768, 1024, 1366 and 1920 measured
   scrollWidth == clientWidth before and after.

   THE CAUSE, one box deeper than the 1.1.3 and 1.2.1 shrink passes reached.
   `.erpal-user` is display: flex, so `.erpal-avatar__btn` is a flex item, and
   it kept the default `min-width: auto` — a min-content floor. At 820 the
   right cluster had been squeezed to 93px and `.erpal-avatar` to NINE pixels,
   while the button inside it still measured 52px and simply painted out of the
   viewport. Nothing clipped it and nothing scrolled; the identical mechanism
   as the search input in 6c416912c, one element further in.

   Four fixes, all shrink-only — no element gains width, nothing new becomes a
   scroll container, and every tab, control and label that renders today still
   renders:

     1. the button gets `min-width: 0`, finishing the pass. This alone clears
        1180 completely (1183 -> 1165), because the display name inside it can
        then ellipsise instead of holding the floor.
     2. under 1200px the bar reclaims 12px of its own right padding, the same
        argument the 768px block already makes about the left: padding is width
        spent on nothing when the bar has run out of room.
     3. under 1100px the avatar caret goes. That breakpoint is where the
        display NAME is already hidden, so the caret is 14px of decoration
        (6px + its gap) on a control that is 30px of identity, and the menu it
        hints at opens by clicking the avatar either way.
     4. the TAB STRIP takes the shrink pressure first. `.erpal-tooltabs` and
        `.erpal-topbar__right` both sat at flex-shrink: 1, so flexbox crushed
        them in proportion and the avatar — which cannot shrink, being a
        30px circle — lost. The tab strip is ALREADY a horizontal scroll
        container by design: clipping it is what it is for, and it keeps all
        seven tabs reachable by scrolling. It is therefore the correct thing to
        squeeze, and the avatar is not.

   Re-measured at 768 / 820 / 900 / 1024 / 1180 / 1366 / 1920 on the live hub:
   scrollWidth == clientWidth at EVERY one, all seven tool tabs still present,
   and the nav toggle hit-tests to itself at every one. */
.erpal-avatar__btn { min-width: 0; }
.erpal-tooltabs { flex-shrink: 6; }
@media (max-width: 1200px) { .erpal-topbar { padding-right: 12px; } }
@media (max-width: 1100px) { .erpal-avatar__caret { display: none; } }

/* ---- responsive: drop labels first, then tabs scroll ---- */
@media (max-width: 1100px) {
  .erpal-avatar__name, .erpal-themetoggle__label { display: none; }
  .erpal-topbar__logotype { display: none; }
}
@media (max-width: 768px) {
  .erpal-tooltabs { display: none; }
  .erpal-searchplus { max-width: none; flex: 2 1 140px; } /* 2026-08-22: search gets grow priority on phones — it was compressing to a sliver */
  /* app.css pads the bar 0 24px, which is 48px of a 360px viewport spent on
     nothing. Reclaiming it (and 4px of each gap) is what lets the burger, the
     logo, the search and the avatar all fit without the document widening —
     measured 401px of content in a 330px box before, 321px after. */
  .erpal-topbar { gap: 8px; padding-left: 12px; padding-right: 12px; }
}

/* --------------------------------------------------------------------------
 * THE PHONE SEARCH — WHAT THE 8/22 FLEX FIX COULD NOT WIN (Troy 2026-08-26:
 * "the search field needs to show up well on a mobile and not get lost").
 *
 * MEASURED on the live hub at 390×844 before this block, on /leads:
 *
 *   .erpal-searchplus input ................  12px wide
 *   .erpal-topbar__right ................... 186px  (Texts · Tour · Hub ·
 *                                                    Day/Night · avatar)
 *   .erpal-avatar ..........................   7px, visibly clipped
 *   topbar scrollWidth 390 in a 375px box .. the bar overflowed the viewport
 *
 * The 8/22 fix IS deployed and IS correct — computed `flex: 2 1 140px` reads
 * live on the element. It loses anyway. Flexbox distributes what is left after
 * the inflexible content, and 186px of secondary chrome that shrinks only to
 * its own min-content is not "what is left"; the avatar inside it is a 30px
 * circle that cannot shrink at all, so the last pixels came out of the search
 * and then out of the document's width. Raising the grow factor a THIRD time
 * argues with the wrong number. So the chrome yields instead.
 *
 * js/erpal-layout.js MOVES Tour, Hub and the Day/Night toggle into the "⋯"
 * menu below 768px and moves them back above it — the nodes themselves, so
 * the behaviours bound to them by js/erpal-topbar.js keep working. What stays
 * inline is the Texts pill (it carries an unread count: an unread text is a
 * waiting human) and the avatar (it is the sign-out path).
 *
 * The bar was ALREADY `position: sticky` (verified live, computed `sticky` at
 * both 1440 and 390) — what it lacked was a floor under `top`, which is set
 * explicitly here so the search is reachable from anywhere in a 7,896px list
 * rather than only from the top of it.
 * ------------------------------------------------------------------------ */
.erpal-tbmore { position: relative; flex: 0 0 auto; display: none; }
.erpal-tbmore__btn {
  display: inline-flex; align-items: center; justify-content: center;
  width: 34px; min-height: 34px;
  border: 1px solid var(--erpal-border); border-radius: 8px;
  background: var(--erpal-surface); color: var(--erpal-muted);
  font-size: 1.1rem; line-height: 1; cursor: pointer;
}
.erpal-tbmore__btn:hover { color: var(--erpal-text); background: var(--erpal-hover); }
/* The menu is a column of the controls THEMSELVES, not links standing in for
   them, so each keeps whatever geometry its own rules give it — hence the
   layout is set on the container and the children are only made full-width. */
.erpal-tbmore__menu { display: flex; flex-direction: column; gap: 4px; min-width: 190px; }
.erpal-tbmore__menu > * { width: 100%; justify-content: flex-start; }

/* A CONTROL IN A MENU IS A MENU ITEM, AND A MENU ITEM NEEDS ITS NAME.
   Every control that lands in here shortens or drops its label somewhere
   below 1200px, because on the BAR the glyph plus the tooltip was the deal:
   .tel-topbadge__label and .erpal-themetoggle__label both go `display: none`
   at ≤1100px (erpal_telephony/css/telephony.css and this file), and the tour
   and hub buttons swap their long label for a short one. Moved into a
   dropdown that reasoning inverts — measured after the first deploy, the menu
   rendered a row containing only "💬" and a row containing only "◐", which is
   a menu of hieroglyphs. There is no width pressure inside a 190px dropdown,
   so the full names come back and the short stand-ins stand down. */
.erpal-tbmore__menu .tel-topbadge__label,
.erpal-tbmore__menu .erpal-themetoggle__label,
.erpal-tbmore__menu .ldtour-label-long,
.erpal-tbmore__menu .erpal-topbar__hublabel {
  display: inline;
  position: static; width: auto; height: auto; overflow: visible; clip: auto;
}
.erpal-tbmore__menu .ldtour-label-short,
.erpal-tbmore__menu .erpal-topbar__hubshort { display: none; }

.erpal-tbmore__btn.is-alert {
  color: var(--erpal-accent); border-color: var(--erpal-accent);
  background: var(--erpal-accent-soft);
}

@media (max-width: 768px) {
  .erpal-tbmore { display: block; }
  /* The bar keeps a real floor under `top` so the search travels with the
     user; z-index is already 40 from app.css and is not touched here. */
  .erpal-topbar { top: 0; }
  /* With the secondary controls gone the cluster stops competing, and the
     search can hold a usable basis instead of a token one. `0 0 auto` on the
     cluster: it may not GROW into the space the overflow menu just freed. */
  .erpal-topbar__right { flex: 0 0 auto; gap: 8px; }
  .erpal-searchplus { flex: 1 1 220px; }

  /* THE TWO CONTROLS THAT PAY FOR THE SEARCH, and why each is affordable:

     [+] QUICK-CREATE. The phone already has this control, larger and closer to
     the thumb: css/erpal-appbar.css puts a raised "+ New" FAB in the bottom
     app bar, and that bar stands down at ≥1024px precisely so it and the top
     bar never both carry it. Two create buttons on a 375px bar is one too
     many, and the one at the bottom is the one a thumb reaches.

     THE LOGO MARK. 26px plus its 8px gap, and on a phone it is the third way
     home on the same screen: the burger immediately to its left opens the rail
     whose first row is the brand and links to the front page, and the bottom
     app bar carries Dashboard. It is the cheapest 34px on the bar and it is
     what takes the search input over 180px. The way OUT to /hub is a separate
     control and is NOT dropped — it moves into the "⋯" menu with its full
     label, which is the standing rule for that button (it shortens, it never
     disappears). */
  .erpal-searchplus .erpal-qc { display: none; }
  .erpal-searchplus .erpal-search { border-radius: 8px; border-right: 1px solid var(--erpal-border); }
  .erpal-topbar__logo { display: none; }
  /* The last four pixels, and they are the difference between a 177px input
     and a 181px one against the ≥180 the order asked for. The bar has no
     background art in its gutter; 2px a side is spent on nothing. */
  .erpal-topbar { padding-left: 10px; padding-right: 10px; }
}

/* NAV-6: command-palette hint inside the global search */
.erpal-search__kbd {
  position: absolute;
  right: 2.4rem;
  top: 50%;
  transform: translateY(-50%);
  font: 600 0.68rem/1 var(--erpal-font, system-ui, sans-serif);
  /* 🪤 --erpal-surface-2 WAS NEVER DECLARED, so this chip's ground was always
     the light literal, in every colour scheme, while its ink flipped with
     --erpal-muted — 2.20:1 in Night on every hub page. A fallback behind a
     token nobody defines is not a fallback, it is the value. The token is now
     declared in erpal-tokens.css for all three palettes (see the note there);
     the ink fallback is a dual-safe grey rather than a light-only one.
     Measured after: 5.10:1 Day, 6.38:1 Night. (d-2026-09-02-055, 2026-09-03.) */
  color: var(--erpal-muted, #5f6b7a);
  background: var(--erpal-surface-2, #f6f8fa);
  border: 1px solid var(--erpal-border, #d8dee9);
  border-radius: 5px;
  padding: 3px 5px;
  pointer-events: none;
}
.erpal-search { position: relative; }
@media (max-width: 820px) { .erpal-search__kbd { display: none; } }