/* PHONE-WIDTH LOCK, 7.00 (2026-08-07): NOW A MEDIA QUERY, NOT AN UNCONDITIONAL LOCK.
   Ryan: "There was a phone width browser version and a full width version. Right now we only
   have the phone width way since the Brain 6 catastrophe."
   The full-width CSS was never deleted. It is alive at app.css 608-620, 627-638 and 668-673
   ("WEBSITE WIDTH, 2026-07-30") and was simply beaten by these eight !important lines, which
   applied at EVERY screen size including a desktop browser. Wrapping them in a max-width query
   restores both: a phone gets the phone column, a wide screen gets the full-width layout that
   was already written and waiting. Nothing was copied in and nothing was deleted.
   Undo: remove the @media wrapper and these rules apply unconditionally again. */
@media (max-width: 900px){
  /* 2026-09-18 (A3, REBUILD_PLAN_2026-09-18 W2.2): the desktop preview frame's own two colours move
     onto the brand. SUPERSEDED: `background:#dfe1e6` (the blue-grey page behind the phone column) and
     `box-shadow:0 0 0 1px #cfd2d8,...` (a blue-grey ring around it). Both are chrome AROUND the phone,
     not inside it, and both read as the old app the moment a Burgundy masthead sits in the middle of
     them. Cream Deep #EDE7D9 is what A1 gave html,body at app.css:16 for the same surface, so the two
     now agree; the ring becomes Rule #D2CFC1, the guide's hairline, 1.45:1 against the cream it sits
     on, which is correct for an ornamental frame edge and is not a boundary anything depends on
     reading (the 430px column inside it is the boundary, and it is Warm Cream on Cream Deep).
     Undo: put #dfe1e6 and #cfd2d8 back. */
  html,body{background:var(--bw-cream-deep)}
  .phone{max-width:430px !important;margin:0 auto !important;box-shadow:0 0 0 1px var(--bw-rule),0 12px 48px rgba(0,0,0,.18)}
  .view{max-width:430px !important}
  .nav{max-width:430px !important;left:50% !important;right:auto !important;margin:0 !important;transform:translateX(-50%) !important}
  .res-helpbar{max-width:430px !important;left:50% !important;right:auto !important;margin:0 !important;transform:translateX(-50%) !important}
  .hdr-row,.topbar-inner{max-width:430px !important}
  .bw-banner img{max-width:430px !important}
}

/* ==== BRAIN 5.9 BUGFIXES (reversible: delete this block) ==== */
/* BUG1+BUG2: center the fixed nav + crisis helpbar with margins, NOT transform.
   transform on a position:fixed element makes it vanish on scroll in iOS Safari (nav disappearing),
   and left:50%;right:auto collapsed the crisis bar to ~200px (the cramped 911/988/211 box). */
.nav, .res-helpbar {
  left:0 !important; right:0 !important;
  transform:none !important;
  margin-left:auto !important; margin-right:auto !important;
}
/* 7.03, 2026-08-12. THE 430px CAP MOVED INTO THE PHONE QUERY, AND ONLY THAT ONE LINE MOVED.
   Ryan, looking at the deployed site: "website version bottom nav buttons missing".
   He was right. Unscoped, this capped the FIXED bottom nav to 430px at every screen size, so on
   a 1280px browser the nav stopped being a bar and became a 430px island floating in the middle
   of the page ON TOP of the event cards, with the page visible either side of it. It reads as
   missing because the bar is gone; only the five buttons are left.
   THIS IS THE SAME BUG THE HEADER OF THIS FILE SAYS WAS FIXED IN 7.00. That fix wrapped the
   block at the top and left this 5.9 block unconditional, so half the lock survived. A fix
   applied at the place you were looking is not a fix.
   The other three declarations here STAY UNSCOPED ON PURPOSE: left/right/transform/margin are
   the 5.9 iOS Safari fix, and a transform on a position:fixed element makes the nav vanish on
   scroll. Only the width was ever the desktop problem.
   Undo: delete this media query and put max-width:430px !important back in the block above. */
@media (max-width: 900px){
  .nav, .res-helpbar { max-width:430px !important; }
}
/* BUG4: on a real touch phone, fill the screen in any orientation. The 430 lock is only a desktop preview frame. */
@media (pointer:coarse){
  /* 2026-09-18 (A3): `background:#ffffff !important` -> Warm Cream. On a real touch phone the .phone
     column fills the screen, so this is the overscroll / rubber-band colour at the top and bottom
     edges; white there flashes the old app every time she pulls the page. The `!important` is KEPT:
     it beats the `html,body{background:var(--bw-cream-deep)}` in the max-width:900px block above,
     which a 430px-wide touch phone also matches, and that is what its own 5.9 comment already says
     this block is for. Undo: put #ffffff back. */
  html, body { background:var(--bw-cream) !important; }
  .phone { max-width:none !important; box-shadow:none !important; }
  .view { max-width:none !important; }
  .nav, .res-helpbar { max-width:none !important; }
  .bw-banner img { max-width:none !important; }
}
/* ==== END 5.9 BUGFIXES ==== */

/* ==== BRAIN 5.97 HOME (Ryan B8 drop hero+date/weather; B6 collapsing MLK banner). reversible: delete this block ==== */
.home-sec[data-sec="hero"]{display:none !important}          /* B8: drop the hero date/time/weather block */
.hdr .bw-banner img{transition:max-height .18s ease}          /* B6: full art at top */
.hdr.compact .bw-banner img{max-height:56px !important;object-fit:cover;object-position:bottom}  /* B6: locked wordmark strip on scroll */
/* ==== END BRAIN 5.97 HOME ==== */

/* BRAIN 5.97: drop redundant home spotlight (Ryan: redundant with Updates). reversible */
.home-sec[data-sec="spotlight"]{display:none !important}

/* ============================================================================
   THE BOTTOM EDGE OF A WINDOW IS NOT GUARANTEED TO BE VISIBLE.
   7.03, 2026-08-12. Ryan, looking at the running app: "the 5 nav buttons at the
   bottom go under my windows search bar".

   MEASURED BEFORE TOUCHING ANYTHING, on his own bytes, in a real browser:
   the nav labels ended SEVEN PIXELS from the bottom of the window, at both
   1440x900 and 430x932. Seven pixels is not a margin, it is a coincidence.
   Anything the operating system draws over the bottom of a window - a Windows
   taskbar or search bar, an auto-hiding dock, an iOS home indicator, an Android
   gesture bar - eats the labels, and the only navigation in the app goes with it.

   AND THE GUARD THAT WAS SUPPOSED TO STOP THIS HAS BEEN DEAD THE WHOLE TIME.
   app.css:513 adds env(safe-area-inset-bottom), but ONLY inside
   @media (display-mode: standalone). brand.css:25 then sets `padding:5px 2px`
   unconditionally, later in the cascade, and the shorthand wipes it out. So the
   safe-area inset has never once applied, in any display mode, on any device.
   An installed iOS PWA has been drawing its nav labels under the home indicator.
   Nobody saw it because nobody measured it; his eye found it first, again.

   THE FIX IS THE RULE, NOT THE NUMBER: reserve real space at the bottom, always,
   in every display mode, and reserve MORE where a windowed OS can overlap
   (pointer:fine = a mouse = a window inside a desktop with chrome around it).
   Phone-flush behaviour is unchanged; the bar still sits on the bottom edge.
   Only the distance from the buttons to that edge changes.

   FIX THE SYSTEM, NEVER PATCH THE CITY: no city name anywhere in this block.
   Undo: delete this block and the labels go back to seven pixels.
   ========================================================================= */
.nav-inner{
  padding-bottom: calc(12px + env(safe-area-inset-bottom, 0px)) !important;
}
/* 36px -> 18px, 2026-08-12. [RYAN, looking at the running preview] "there is too much empty space
   around the buttons". His eye is the reference. 18px still clears the window bottom by ~20px,
   against the 7px it had this morning, so the taskbar problem stays fixed with a third of the
   dead space. If it clips again on his machine this number is the only thing that changes. */
@media (pointer:fine) and (min-width:640px){
  .nav-inner{ padding-bottom: calc(18px + env(safe-area-inset-bottom, 0px)) !important; }
}