/* ─────────────────────────────────────────────
   auth.css
   Everything login.html and register.html render. Private to those two
   pages: no other page links this file.

   REQUIRES base.css, LINKED FIRST — the element reset and the design
   tokens live there. This file defines no tokens of its own; every
   var() below resolves from base.css. The reset it used to declare
   itself was a byte-for-byte duplicate of base.css's and is gone.

   ── AND base.css NEEDS ITS OWN Web.config ENTRY TO REACH THESE PAGES ──
   These are the only two pages served to ANONYMOUS users. Web.config's
   global <deny users="?"/> blocks every asset that has no explicit
   <location> allow block, and a blocked stylesheet is NOT a 404: the
   request is answered with login.html's own markup, which the browser
   discards as the wrong content type. The page then renders with no
   reset, no tokens, and every var() below resolving to nothing. THERE
   IS NO ERROR AND NO CONSOLE WARNING. Worse, IT CANNOT BE SEEN WHILE
   SIGNED IN — an authenticated request for the same file is allowed,
   so the page looks correct to anyone testing with a session. Test
   signed out, or in a private window.

   STILL A PLACEHOLDER FOR ITS ACTUAL STYLING (Item 2). Item 253's
   Phase B gave this file the shared palette and a dark mode it had
   never had. It did NOT design these pages. What they should LOOK
   like is Item 2's question and is still open.

   WHERE color-scheme WENT, AND WHY IT IS NO LONGER HERE (Item 253,
   Phase D). Phase B put the solution's first and only color-scheme in
   this file, for login.html's "Keep me signed in" checkbox: tokens
   paint what a stylesheet draws and do not reach what the BROWSER
   draws, so a checkbox — painted almost entirely by the UA, with no
   background or color property reaching its box, its border or its
   tick — stayed light against a dark card. That paragraph closed by
   leaving open whether it belonged in base.css, and asked for the
   question to be settled ONCE for all four pages rather than twice.

   IT IS NOW IN base.css AND THESE PAGES ARE UNCHANGED. base.css is
   linked first here, the declaration is on the same :root, and the
   computed result is identical — nothing about these two pages looks
   any different for the move. What changed is that Allium.html and
   admin.html get it too: Phase D found the same control in the same
   condition on both, a checkbox for every boolean field in edit mode
   and admin.html's .role-select popup, with the palette flipping
   around them exactly as it does here.

   SO THIS FILE'S :root IS GONE RATHER THAN EMPTIED. color-scheme was
   the only thing in it, and this file still defines no tokens of its
   own. A rule left standing with nothing in it would read as a place
   to put things.
   ───────────────────────────────────────────── */

body {
  font-family: var(--font-sans);
  background: var(--surface-page);
  color: var(--text-primary);
  min-height: 100vh;
  display: flex;
  align-items: center;
  justify-content: center;
  padding: 1rem;
}

.auth-page  { width: 100%; max-width: 360px; }

.auth-card  {
  background: var(--surface);
  border: 0.5px solid var(--border-mid);
  border-radius: var(--radius-lg);
  padding: 2rem 1.75rem;
  display: flex;
  flex-direction: column;
  gap: 1rem;
}

.auth-title { font-size: 20px; font-weight: 600; }

.auth-field { display: flex; flex-direction: column; gap: 5px; }
.auth-field label { font-size: 13px; color: var(--text-secondary); }

/* GEOMETRY FOR EVERY input IN A FIELD. THE CHECKBOX MATCHES THIS RULE
   AND TAKES NOTHING FROM IT, WHICH IS NOT WHAT THIS COMMENT USED TO
   SAY. It claimed #remember on login.html "has always taken this
   padding, border and radius", and used that as the reason not to
   narrow the selector. MEASURED IN A BROWSER (Item 253, Phase D): the
   password field on this rule computes border-radius 10px, while the
   checkbox computes 0px for border-radius, padding AND border-width.
   The rule matches it — element.matches('.auth-field input') is true
   and the Styles pane shows nothing struck through — so the
   declarations ARRIVE and are NOT APPLIED. That is a property of the
   control rather than of the cascade.

   THE MECHANISM IS UNEXPLAINED AND IS DELIBERATELY NOT GUESSED HERE. A
   plausible-sounding reason written into a comment is exactly how the
   false claim above survived: it read as a measurement and was never
   one. If it matters, it is one experiment — set appearance:none on
   that element in the Styles pane and see whether the three
   declarations appear.

   WHAT THIS CHANGES: the argument that protected the rule's scope has
   gone. Narrowing this selector would NOT change how the checkbox
   looks, because nothing here reaches it. WHETHER TO NARROW IT IS
   STILL ITEM 2's CALL — but it is now a scope question standing on a
   true premise instead of a false one.

   The border was rgba(0,0,0,0.18) and is now --border-mid (0.14). The
   shift in light mode is slight and the point is dark mode: a black
   rgba border on a dark card is INVISIBLE, and the token flips. Same
   consequence-of-a-ruling as admin.css's error box (Item 253). */
.auth-field input {
  padding: 9px 11px;
  border: 0.5px solid var(--border-mid);
  border-radius: var(--radius-md);
  font-size: 15px;
  outline: none;
}

/* COLOUR FOR THE TEXT-ENTRY inputs ONLY, split from the geometry rule
   above so the checkbox keeps its shape without being given a surface
   fill it cannot use — color-scheme paints that one. These two
   declarations did not exist before Phase B, which is why no literal
   census ever flagged them: the fault was an ABSENCE, and it only
   became visible once the card behind them started flipping. */
.auth-field input[type="text"],
.auth-field input[type="email"],
.auth-field input[type="password"] {
  background: var(--surface-inset);
  color: var(--text-primary);
}

/* THE FOCUS RING TAKES A TOKEN NAMED FOR TEXT, AND THAT IS DELIBERATE
   (Item 260). The geometry rule above sets outline: none, so this border IS
   the focus indicator — the only thing telling a keyboard user where they are,
   which is why it moved with the text while decorative borders did not.
   var(--accent) measured 2.17:1 against --surface; --accent-text measures
   5.70:1. THESE ARE THE ONLY ANONYMOUS PAGES, so this is
   also the only focus ring in the solution an unauthenticated visitor ever
   sees — and, per the header above, the only one whose stylesheet can silently
   fail to arrive at all. Check it signed out. */
.auth-field input:focus { border-color: var(--accent-text); }

.auth-field--inline { flex-direction: row; align-items: center; gap: 8px; }
.auth-field--inline label { color: var(--text-primary); font-size: 14px; }

/* TAKES --on-accent SINCE ITEM 253's PHASE C. This rule carried a
   literal `white` through Phase B, deferred only because base.css had
   no on-accent token to reach for. It has one now, and admin.css's
   .admin-btn — which kept the same literal for the same reason at
   Phase A — took it in the same delivery. THAT SENTENCE USED TO END
   "the rendered value is unchanged (#ffffff)", AND ITEM 260 FALSIFIED
   IT: --on-accent is now #1a1a18, because white on the accent measured
   2.17:1 in BOTH themes and near black measures 8.05:1. This
   button therefore carries a near-black label without this
   rule changing by a character, which is what taking the token bought.
   The token still has no dark variant, because --accent still does not
   flip — Item 260 deliberately left the fill alone and split a new
   --accent-text off for the accent used AS text.

   THE COMMENT THIS REPLACED PUT THAT FIGURE AT TEN, AND IT WAS WRONG
   TWICE OVER — recorded here because a stale count in a comment is
   read as a measurement. A value-position count of allium.css finds
   SEVEN, not ten: a word-boundary search for `white` also matches
   `white-space`, so three declarations that are not colours at all
   were in the total. And of the seven, only FOUR sit on the accent.
   The other three sit on black scrims and deliberately did NOT take
   this token; base.css's comment at the token records which and why. */
.auth-btn {
  width: 100%;
  padding: 10px;
  background: var(--accent);
  color: var(--on-accent);
  border: none;
  border-radius: var(--radius-md);
  font-size: 15px;
  font-weight: 600;
  cursor: pointer;
}

/* KEPT, UNLIKE admin.css's equivalent, AND THE DIFFERENCE IS THE
   SEARCH, NOT THE RULE. .admin-btn:disabled was deleted at Item 232's
   residue because the search for a caller was COMPLETE — one script,
   no occurrence of "disabled" in it, four buttons none of which carry
   the attribute. No such search has been run against login.js or
   register.js. "No callers" is a question generator, not a verdict,
   unless the search is complete. */
.auth-btn:disabled { opacity: 0.6; cursor: not-allowed; }

.auth-error   {
  font-size: 13px; color: var(--error-text);
  background: var(--error-surface);
  border: 0.5px solid var(--error-border);
  border-radius: var(--radius-sm);
  padding: 9px 11px;
}
.auth-success {
  font-size: 13px; color: var(--success-text);
  background: var(--success-surface);
  border: 0.5px solid var(--success-border);
  border-radius: var(--radius-sm);
  padding: 9px 11px;
}

.auth-link { font-size: 13px; color: var(--text-secondary); text-align: center; }
/* THE COLOUR IS THE ONLY THING MARKING THIS AS A LINK AT REST, since
   text-decoration is none until hover — so its contrast is load-bearing rather
   than decorative, and on these pages it is the sole route to the other one.
   --accent read 2.17:1 on the card in light; --accent-text reads 5.70:1
   (Item 260). Same change, same reasoning, as allium.css's .field-val a. */
.auth-link a { color: var(--accent-text); text-decoration: none; }
.auth-link a:hover { text-decoration: underline; }