/* ═══════════════════════════════════════════════════════════════════════════
   app.css — the ONLY app-owned stylesheet. Loaded after the compiled Metronic
   theme (assets/css/styles.css), so rules here win over the theme without
   editing a vendor file. Keep it small: corrections to theme defaults that
   apply app-wide, never page-specific styling (that stays inline or in the
   page). Utility classes still obey the compiled-CSS trap in CLAUDE.md — this
   file is not a place to invent new ones.
   ═══════════════════════════════════════════════════════════════════════════ */

/* ── Notes / remark boxes ────────────────────────────────────────────────────
   SUP-260819-256D5, SUP-260820-75B94 and SUP-260821-48526, all one defect
   reported three times on three pages. The client's ask on the third:
   "इस पूरे Software में एक समान Pattern ही रखेंगे तो ज़्यादा उचित रहेगा."

   .kt-input pins EVERY textarea to a single-line height (height: calc(var(--spacing)*8.5))
   and sets padding-inline only. Two consequences, both visible to the client:
     1. no padding-block, so typed text sits flush against the top border while
        empty space collects underneath;
     2. the height pin silently overrides rows="4"/"5", so boxes authored as
        multi-line rendered as 34px slivers and clipped their own content —
        his Credit Assessment screenshot shows the AI-suggested checklist cut
        off mid-sentence.

   One rule fixes both everywhere: release the pin, pad the text, and let the
   box size itself to what is typed. Every notes box in the app now behaves the
   way the tele-verification boxes he approved of do — one line to start,
   growing as you type, text centred while short.

   field-sizing is Chrome/Edge 123+; where it is unsupported the box simply
   stays at min-height and scrolls, which is what these boxes did before. Pages
   that need a different size (e.g. the shared AttemptLog row, which matches the
   34px Status select beside it) override with an inline style, which wins. */
textarea.kt-input {
    height: auto;
    min-height: 38px;
    max-height: 220px;
    padding-block: 0.5rem;
    field-sizing: content;
    resize: vertical;
}

/* ── Capitalised entry, visible while typing ─────────────────────────────────
   SUP-260818-41EDD, follow-up of 2026-08-28. EntryCasePolicy already upper-cases
   names, addresses and business names when they are SAVED, but the operator typed
   in lower case and watched the value change under them on save:
   "उचित ये रहेगा कि जब आप लिखते हैं तभी वो capital case में दिखे तो confusion नहीं होगा."

   text-transform is display-only: the DOM value stays exactly as typed and the
   stored value is still decided server-side by EntryCasePolicy.Normalise. That is
   deliberate — the CSS cannot introduce a data defect, it can only stop the screen
   surprising the operator. Devanagari has no case, so Hindi entry is unaffected,
   which matters because this client's staff type in both scripts.

   SCOPE IS THE WHOLE POINT. `entry-upper` is on exactly the 59 inputs whose values
   pass through EntryCasePolicy — nowhere else. A styled field that is NOT normalised
   would show upper case and save what was typed: a display that lies, which is worse
   than the original complaint. Adding a field here means adding it to Normalise in
   the same commit. Deliberately absent: e-mail, phone, Aadhaar/PAN, notes and
   remarks, dropdown values, and system-stamped names — see EntryCasePolicy for why.

   Placeholders opt out: uppercasing "Enter customer name" reads as shouting and
   tells the operator nothing about what to type. */
input.entry-upper,
textarea.entry-upper {
    text-transform: uppercase;
}

input.entry-upper::placeholder,
textarea.entry-upper::placeholder {
    text-transform: none;
}