/* Admin Console -> SMTP configuration -> Outbound notifications. Presentation and information
   architecture only — no RPC changed: TEAM_EMAIL_EVENTS is still the one event catalogue,
   admin_set_team_email() the one write path. Behaviour lives in admin-email.js's
   wireOutboundLocalTabs(). #smtpPane gained a local tablist and a narrow-screen reading order
   that differs from the desktop's column grouping; everything else sizes the pane's grid to
   the wireframe's two-thirds/one-third split.

   Reused, not invented (core rule 4): the tab strip is `.at-tabs`/`.at-tab` (alt-components.css,
   the same control okrs.html's view switch wears); the team-events dialog reuses
   `.modal-overlay`/`.modal-card`/`.modal-title-row`/`.modal-footer` (CSS/components.css) and
   needs nothing declared here.

   admin-smtp-teams-paging.test.js and admin-paneling.test.js both assert exact substrings on
   `.sec-stack` and `#emailAuditPanel`'s opening tags — neither test is this lane's, so new
   structure below is addressed by selector (`#smtpPane.pane-grid.on > .sec-stack`, `#smtpPane
   #emailAuditPanel`) rather than by adding a class or id to those tags. */

/* The strip spans the pane's full grid width regardless of column count, or it would land in
   the first cell and push the stack beside it onto the same row. */
#smtpPane.pane-grid.on > .at-tabs.ecfg-tabs{
  grid-column: 1 / -1;
  /* Span and width are different questions: `grid-column` answers which ROW; a grid item's
     default `justify-self:stretch` is what pulled the box to the full track despite `.at-tabs`
     being inline-flex, so `justify-self:start` gives the content-sized box back. */
  justify-self: start;
}

/* Neither mount is a panel block, deliberately — admin-paneling.test.js counts exactly four by
   name (Teams, Application email, Email bench, the delivery audit); a fifth here, even hidden,
   would break that count. Both get the full row for the same reason the audit's `.is-double`
   stack does: a tab panel wants the pane's whole width. Neither needs an `order` below — the
   reorder there exists because the four OUTBOUND sections are visible together; a tab panel is
   only ever visible alone beneath the strip. */
#smtpPane.pane-grid.on > .ecfg-inbound-mount,
#smtpPane.pane-grid.on > .ecfg-intel-mount{
  grid-column: 1 / -1;
}

/* A hidden region stays hidden regardless of what else on it sets `display` — `.sec-stack` and
   `.sec-section` both set their own, at higher specificity than a bare `[hidden]`, so the
   attribute alone would be silently overruled. Scoped to this pane, not written globally. */
#smtpPane [hidden]{
  display: none !important;
}

/* ================= THE DESKTOP SPLIT: ROUGHLY TWO-THIRDS, ONE-THIRD =================
   The shared `.pane-grid` rule (admin.html) goes 2 equal columns at 900px, 3 equal at 1400px —
   a 2:1 split only above 1400px. Narrowed here to the 900-1400 range that rule doesn't already
   cover correctly; left alone outside it so this doesn't fight Overview/Security's own grid. */
@media (min-width: 1181px) and (max-width: 1399.98px){
  #smtpPane.pane-grid.on{
    grid-template-columns: minmax(0, 2fr) minmax(300px, 1fr);
  }
}

/* ================= RESPONSIVE ORDER (<=1180px) =================
   Wireframe order (Application email, Teams, Email bench, audit) is neither DOM order nor the
   desktop's column order, because the desktop groups by what depends on what — stacked that way
   the gating switch would land at the bottom, under the full roster and the delivery table.
   `display:contents` on the two stacks drops their own box out of the grid while leaving their
   children as direct grid items, so each of the four can be placed by `order` as if always a
   sibling of the tab strip — targeted structurally (`> .sec-stack`) because neither wrapper's
   opening tag may change (see file header). */
@media (max-width: 1180px){
  #smtpPane.pane-grid.on{
    grid-template-columns: minmax(0, 1fr);
  }
  #smtpPane.pane-grid.on > .sec-stack{
    display: contents;
  }
  #smtpPane .ecfg-tabs{ order: 0; }
  #smtpPane .ecfg-appemail-panel{ order: 1; }
  #smtpPane .ecfg-teams-panel{ order: 2; }
  #smtpPane .ecfg-bench-panel{ order: 3; }
  #smtpPane #emailAuditPanel{ order: 4; }
}

/* ================= THE TEAM EVENTS DIALOG =================
   Nothing to declare — teamEventsDialogMount() builds entirely from classes CSS/components.css
   and admin.html's own <style> already style. The one seam: `.smtp-team-events` carries a
   border-top meant for sitting under a roster row header, which reads as a stray line when it
   is a dialog body with nothing above it. */
.modal-card .smtp-team-events{
  padding: 0;
  border-top: none;
}