/* ===========================================================================
   ΤΟ ΠΛΕΓΜΑ ΤΩΝ KPI — ΠΟΣΕΣ ΣΤΗΛΕΣ, ΚΑΙ ΓΙΑΤΙ ΟΧΙ ΑΠΟ ΤΗΝ ΟΘΟΝΗ

   ── ΤΙ ΕΣΠΑΖΕ ─────────────────────────────────────────────────────────────

   Το πλέγμα έλεγε `grid-cols-1 md:grid-cols-2 lg:grid-cols-4`: τρία σκαλιά
   κλειδωμένα στο ΠΛΑΤΟΣ ΤΗΣ ΟΘΟΝΗΣ. Αλλά το πλάτος που έχει πραγματικά στη
   διάθεσή του δεν προκύπτει από την οθόνη — αλλάζει κατά ~500px από δύο
   πράγματα που η οθόνη δεν βλέπει:

       sidebar ανοιχτό / συμπτυγμένο     240px  ή   72px
       bonus card δίπλα / κλειστή          0px  ή  312px

   Σε laptop 1280 με ανοιχτό sidebar και ανοιχτή bonus card, οι «τέσσερις
   στήλες» ήταν 152px η καθεμία. Μετρημένα εκεί: 32 στοιχεία με κομμένο
   περιεχόμενο. Η οθόνη έλεγε lg· η πραγματικότητα ήταν στενότερη από κινητό.

   ── ΟΙ ΤΡΕΙΣ ΑΡΙΘΜΟΙ, ΜΕΤΡΗΜΕΝΟΙ ─────────────────────────────────────────

   Με το tools/preview/overview.html, σαρώνοντας πλάτη και μετρώντας πόσα
   στοιχεία έχουν scrollWidth > clientWidth (δηλαδή κρύβουν περιεχόμενο):

       απλή κάρτα, ελάχιστο πλάτος στήλης           187px
       live κάρτα στοιβαγμένη                       284px
       live κάρτα δίπλα-δίπλα                       562px

   Δεσμευτικό είναι το πρώτο: η live κάρτα πιάνει δύο στήλες, οπότε στα 190px
   στήλη παίρνει 404px και στοιβάζεται άνετα. Γι' αυτό ο ελάχιστος στύλος
   είναι 190px και όχι κάτι μεγαλύτερο.

   ── ΓΙΑΤΙ auto-fit ΚΑΙ ΟΧΙ ΣΚΑΛΙΑ ─────────────────────────────────────────

   Το `repeat(auto-fit, minmax(190px, 1fr))` λέει ακριβώς αυτό που θέλουμε:
   «όσες στήλες χωρέσουν με τουλάχιστον 190px». Χωρίς breakpoints, χωρίς να
   μαντεύουμε συσκευή, και σωστό ΚΑΙ όταν αλλάξει το sidebar ή ανοίξει η
   bonus card — γιατί ο υπολογισμός γίνεται πάνω στο πλάτος ΤΟΥ ΠΛΕΓΜΑΤΟΣ.

   Το `max(190px, (100% - 72px) / 4)` είναι η οροφή των τεσσάρων στηλών: το
   δεύτερο σκέλος είναι ακριβώς όσο θα ήταν μια στήλη αν ήταν τέσσερις (τρία
   κενά × 24px = 72px). Όταν χωράνε τέσσερις, το ελάχιστο γίνεται ίσο με το
   ένα τέταρτο και το auto-fit δεν μπορεί να βάλει πέμπτη. Χωρίς αυτό, μια
   οθόνη 2560px θα έβγαζε οκτώ κολώνες από μόνη της.

   ── ΤΟ ΑΝΟΙΓΜΑ ΤΗΣ LIVE ΚΑΡΤΑΣ ────────────────────────────────────────────

   Η live κάρτα πιάνει δύο στήλες — εκτός αν υπάρχει μία. Με μία στήλη το
   `span 2` δημιουργεί σιωπηλά δεύτερη, υπονομευμένη στήλη και το πλέγμα
   ξεχειλίζει πλάγια.

   Αυτό ΔΕΝ γίνεται με media query: το ερώτημα είναι «πόσο πλατύ είναι το
   πλέγμα», όχι «πόσο πλατιά είναι η οθόνη». Το πλέγμα δηλώνεται container
   και η κάρτα — που είναι ΠΑΙΔΙ του — το ρωτάει. Ένα στοιχείο δεν μπορεί να
   ρωτήσει τον εαυτό του, γι' αυτό οι στήλες βγαίνουν από το auto-fit και
   μόνο το άνοιγμα από το container query.

   404px = δύο στήλες των 190 συν ένα κενό 24.
   =========================================================================== */

[data-kpi-grid] {
    container: kpigrid / inline-size;
    grid-template-columns: repeat(auto-fit, minmax(max(190px, (100% - 72px) / 4), 1fr));

    /* ── ΓΙΑΤΙ dense, ΚΑΙ ΓΙΑΤΙ ΕΙΝΑΙ ΑΚΙΝΔΥΝΟ ────────────────────────────
       Μόλις ένα στοιχείο πιάνει δύο γραμμές, η κανονική τοποθέτηση δεν
       γυρίζει ποτέ πίσω: ο δρομέας προχωράει μόνο μπροστά, οπότε κάθε κελί
       που προσπεράστηκε μένει κενό για πάντα. Μετρημένο σε iPad Pro 13 με
       συμπτυγμένο sidebar (τέσσερις στήλες): ΤΕΣΣΕΡΑ κενά κελιά — μισό
       πλέγμα λευκό, με τα KPI στριμωγμένα στην επάνω γραμμή.
       Το `dense` γεμίζει αυτές τις τρύπες με τα επόμενα 1×1.

       Το τίμημα του `dense` είναι ότι η οπτική σειρά μπορεί να διαφέρει από
       τη σειρά του DOM. Εδώ δεν διαφέρει ποτέ ΧΩΡΙΣ λόγο: τρύπα υπάρχει
       μόνο στη ζώνη όπου η live κάρτα πιάνει δύο γραμμές (618–1180). Κάτω
       από 618 δεν υπάρχει τίποτα δίπλα της και πάνω από 1180 πιάνει μία
       γραμμή — και στις δύο περιπτώσεις δεν υπάρχει τρύπα να γεμίσει, άρα
       το `dense` είναι αδρανές. Το desktop δεν το αγγίζει καθόλου. */
    grid-auto-flow: dense;
}

/* ── ΟΙ LIVE ΚΑΡΤΕΣ ΠΡΩΤΕΣ — ΚΑΙ ΣΕ TABLET ───────────────────────────────
   Ο κανόνας υπήρχε ήδη, σε JS: το orderKpisForViewport() του views.js
   ανεβάζει τις live κάρτες μπροστά ΚΑΤΩ ΑΠΟ 768px ΟΘΟΝΗΣ. Το σκεπτικό του
   —«μια κάρτα που λέει ΤΩΡΑ δεν πρέπει να είναι κάτω από το fold»— δεν
   σταματά στα 768· σταματούσε εκεί μόνο επειδή ρωτούσε την οθόνη.

   Και σε tablet δεν είναι μόνο θέμα σειράς, είναι θέμα κενού χώρου. Με τη
   διάταξη του config (live, μικρό, μικρό, live, μικρό, μικρό) η δεύτερη
   live κάρτα πέφτει στη μέση: κόβει το μπλοκ στα δύο, και ό,τι μένει
   ακάλυπτο δεν έχει πια ποιος να το γεμίσει. Με τις δύο live μπροστά, οι
   τέσσερις μικρές πέφτουν όλες μαζί από κάτω — ΟΡΙΖΟΝΤΙΑ, που είναι
   ακριβώς το ζητούμενο.

   Το `order` ΕΠΙΤΡΕΠΕΤΑΙ εδώ όπου το `grid-template-columns` δεν επιτρεπόταν:
   είναι ιδιότητα του ΠΑΙΔΙΟΥ. Ένα container query δεν στυλάρει τον container
   του — στυλάρει τα παιδιά του, και η σειρά τοποθέτησης είναι δική τους.

   Πάνω από 1180 ΔΕΝ ισχύει, σκόπιμα: εκεί η live κάρτα πιάνει μία γραμμή,
   δεν δημιουργεί τρύπα, και η σειρά που έβαλε ο admin είναι η σειρά που
   σχεδίασε για αυτή την επιφάνεια. Το desktop μένει byte για byte ίδιο. */
@container kpigrid (max-width: 1179.98px) {
    [data-kpi-grid] > .live-card { order: -1; }
}

/* ── ΤΙ ΣΧΗΜΑ ΠΑΙΡΝΕΙ Η LIVE ΚΑΡΤΑ ─────────────────────────────────────────

   Τέσσερις ζώνες, όλες από μετρημένους αριθμούς. Δεν ρωτάμε ποτέ «είναι
   tablet;» — ρωτάμε πόσο πλατύ είναι το πλέγμα.

   <404      ΜΙΑ ΣΤΗΛΗ. Η κάρτα παίρνει τη στήλη· τίποτα δίπλα της.
   404–618   ΔΥΟ ΣΤΗΛΕΣ. Παίρνει και τις δύο, δηλαδή όλη τη γραμμή. Πάλι
             τίποτα δίπλα της, οπότε το ύψος της δεν κοστίζει σε κανέναν.
   618–1180  ΕΔΩ ΗΤΑΝ ΤΟ ΛΑΘΟΣ. Δες παρακάτω.

             Το 618 είναι όπου μπαίνει ΤΡΙΤΗ στήλη — δηλαδή η πρώτη φορά που
             κάθεται κάτι ΔΙΠΛΑ στη live κάρτα. Ήταν 718 και άφηνε κενό: στα
             618–718 υπήρχαν τρεις στήλες αλλά η κάρτα δεν καρφωνόταν, οπότε
             η αυτόματη τοποθέτηση έστελνε τη μία live αριστερά και την άλλη
             δεξιά. Ακριβώς αυτό φάνηκε σε iPad με ανοιχτή bonus card.
   1180+     Αρκετό πλάτος ώστε δύο στήλες να δίνουν τα 570 που θέλει το
             εσωτερικό σπάσιμο. Δύο στήλες επί ΜΙΑ γραμμή, δίπλα-δίπλα: η
             διάταξη του desktop, αμετάβλητη.

   ── Η ΖΩΝΗ 718–1180 ──────────────────────────────────────────────────────

   Η κάρτα κρατούσε `span 2` σε ΜΙΑ γραμμή ενώ μέσα της ήταν στοιβαγμένη:
   ύψος δύο καρτών σε γραμμή μιας. Οι μικρές δίπλα της τεντώνονταν στο ίδιο
   ύψος και έμεναν με τον αριθμό τους στην κορυφή και μισή κάρτα κενό από
   κάτω — πληροφορία που χανόταν, όχι απλώς άσχημη στοίχιση.

   Η διόρθωση είναι μία λέξη: `grid-row: span 2`. Η κάρτα καταλαμβάνει ΔΥΟ
   γραμμές, όσο ύψος πραγματικά χρειάζεται, και οι μικρές δίπλα της γίνονται
   τετράγωνες δύο-δύο. Ίδιο ύψος μπλοκ, κανένα κενό.

   ΓΙΑΤΙ ΟΧΙ «ΜΙΑ ΣΤΗΛΗ ΕΠΙ ΔΥΟ ΓΡΑΜΜΕΣ». Δοκιμάστηκε πρώτο, και μετρήθηκε:
   η κάρτα έπαιρνε 229px ενώ στοιβαγμένη θέλει 284 — κοβόταν το υποσέλιδο.
   Μια ΟΜΟΙΟΜΟΡΦΗ στήλη δεν γίνεται ποτέ αρκετά φαρδιά εδώ: στις τρεις
   στήλες θα χρειαζόταν πλέγμα 900px, αλλά στα 832 μπαίνει ήδη τέταρτη. Και
   φαρδύτερη ΠΡΩΤΗ στήλη δεν γίνεται να δηλωθεί: οι στήλες ανήκουν στο
   πλέγμα, που είναι ο ΙΔΙΟΣ ο container — και ένα container query δεν
   στυλάρει τον container του, μόνο τα παιδιά του. Το `span 2` το λύνει από
   τη μεριά του παιδιού, που είναι η μεριά που επιτρέπεται.

   Το ότι οι live κάρτες βγαίνουν ΑΡΙΣΤΕΡΑ δεν το εξασφαλίζει πια κάρφωμα σε
   στήλη — το εξασφαλίζει το `order: -1` παρακάτω, που τις τοποθετεί πρώτες σε
   άδειο πλέγμα. Το κάρφωμα το έκανε κι αυτό, αλλά άφηνε πίσω του τρύπες που
   δεν γέμιζε τίποτα· δες το σχόλιο στη ζώνη των 618.

   1180 = 4 × 277 + 72, όπου 277 είναι η στήλη που δίνει στην κάρτα 578 ≥ 570. */

[data-kpi-grid] > .live-card {
    grid-column: span 1;
}

@container kpigrid (min-width: 404px) {
    [data-kpi-grid] > .live-card {
        grid-column: span 2;
    }
}

@container kpigrid (min-width: 618px) {
    [data-kpi-grid] > .live-card {
        /* ΗΤΑΝ `1 / span 2` — καρφωμένο στην πρώτη στήλη. Το κάρφωμα έλυνε
           πράγματι το «μια live αριστερά, μια δεξιά», αλλά με τρόπο που
           κόστιζε τα μισά κελιά: καρφωμένη στη στήλη 1, η ΔΕΥΤΕΡΗ live δεν
           μπορεί ποτέ να καθίσει δίπλα στην πρώτη — ανοίγει υποχρεωτικά νέο
           μπλοκ, και με μόνο τέσσερα μικρά KPI το ένα από τα δύο μπλοκ
           μένει μισοάδειο ό,τι και να κάνει το `dense`.

           Δεν χρειάζεται πια: το `order: -1` παραπάνω βάζει και τις δύο live
           μπροστά, οπότε τοποθετούνται ΠΡΩΤΕΣ, σε άδειο πλέγμα. Με τέσσερις
           στήλες πιάνουν 1-2 και 3-4 της ίδιας γραμμής και τα μικρά πέφτουν
           οριζόντια από κάτω· με τρεις, η δεύτερη δεν χωράει δίπλα και πάει
           κάτω από την πρώτη — πάλι στη στήλη 1. Και στις δύο περιπτώσεις
           καμία live κάρτα δεν βρίσκεται δεξιά από μικρές. */
        grid-column: span 2;
        grid-row: span 2;
    }
}

@container kpigrid (min-width: 1180px) {
    [data-kpi-grid] > .live-card {
        grid-column: span 2;
        grid-row: span 1;
    }
}

/* ===========================================================================
   ΟΙ ΔΙΣΚΟΙ ΜΙΑΣ ΓΡΑΜΜΗΣ ΚΡΑΤΑΝΕ ΤΟ ΙΔΙΟ ΥΨΟΣ

   ── ΤΙ ΕΣΠΑΖΕ ─────────────────────────────────────────────────────────────

   Ο δίσκος της απλής κάρτας σπάει σε δεύτερη γραμμή όταν το chip του στόχου
   και τα sub-metrics δεν χωράνε δίπλα-δίπλα. Σπάει όμως ΑΝΑ ΚΑΡΤΑ, ανάλογα με
   το τι έχει μέσα της — και οι κάρτες μιας γραμμής έχουν διαφορετικό
   περιεχόμενο. Μετρημένο σε iPad Pro 13 με συμπτυγμένο sidebar, τέσσερις
   κάρτες στην ίδια γραμμή του πλέγματος:

       AHT, AVERAGE HOLD    δίσκος ξεκινά στο 631   (μία γραμμή,  24px)
       HANDLED CALLS, QA    δίσκος ξεκινά στο 610   (δύο γραμμές, 45px)

   Ίδιο ύψος κάρτας, ίδιο πλάτος, ίδια γραμμή — και η οριζόντια γραμμή που
   χωρίζει το σώμα από τον δίσκο σε ΔΙΑΦΟΡΕΤΙΚΟ σημείο κατά 21px. Τέσσερις
   κάρτες, δύο ύψη, καμία ευθυγράμμιση.

   ── ΓΙΑΤΙ ΔΕΝ ΛΥΝΕΤΑΙ ΜΕΣΑ ΣΤΗΝ ΚΑΡΤΑ ────────────────────────────────────

   Μια κάρτα δεν ξέρει τι ύψος δίσκου έχει η διπλανή της. Το ερώτημα «σπάει
   κάποιος δίσκος εδώ μέσα;» είναι ερώτημα ΤΟΥ ΠΛΕΓΜΑΤΟΣ, γι' αυτό ζει εδώ:
   το `:has()` κοιτάζει αν ΟΠΟΙΑΔΗΠΟΤΕ κάρτα έχει δεύτερη σειρά, και αν ναι,
   τη θέση την κρατάνε ΟΛΕΣ. Η λύση είναι η ίδια που έχει ήδη το TRAY_ITEM_H
   του KPICard.js: το ύψος παύει να μετριέται και αρχίζει να δηλώνεται.

   ── ΤΟ ΟΡΙΟ ΤΩΝ 1280, ΜΕΤΡΗΜΕΝΟ ──────────────────────────────────────────

   Σαρώθηκαν πλάτη πλέγματος 800→2000 στον browser, με τα πραγματικά δεδομένα
   του PPC. Ο δίσκος σπάει σε κάθε πλάτος ΜΕΧΡΙ τα 1240· στα 1280 (στήλη
   302px) κανένας δεν σπάει, και δεν ξανασπάει πουθενά πιο πάνω.

   Πάνω από εκεί ο κανόνας ΔΕΝ ισχύει, σκόπιμα: θα δέσμευε 28px κενού δίσκου
   σε κάθε κάρτα κάθε μεγάλης οθόνης για ευθυγράμμιση που δεν χρειάζεται.

   🔴 Το 1280 είναι μετρημένο για ΑΥΤΟ το περιεχόμενο. Αν ένα άλλο project
   βάλει μακρύτερο chip στόχου ή τέταρτο sub-metric, θα σπάει και πιο πάνω και
   η ευθυγράμμιση θα χαθεί εκεί. Η αστοχία είναι αισθητική, όχι λειτουργική —
   τίποτα δεν κόβεται — αλλά αν εμφανιστεί, ο αριθμός ξαναμετριέται, δεν
   μαντεύεται.
   ========================================================================= */

@container kpigrid (max-width: 1279.98px) {
    [data-kpi-grid]:has(.kpi-tray-row > .kpi-subrow) .kpi-tray-row {
        /* Δύο σειρές των 24px (TRAY_ITEM_H) συν το gap-y-1 ανάμεσά τους. Το
           ύψος βγαίνει από ΜΙΑ σταθερά, όχι από το line-height μιας γραμματοσειράς
           — αλλιώς μια αλλαγή μεγέθους γραμμάτων θα ξεχαρβάλωνε τη στοίχιση. */
        min-height: calc(2 * 24px + 4px);
        /* Ο δίσκος που ΔΕΝ σπάει κάθεται στη μέση του χώρου που κράτησε, όχι
           κολλημένος στην κορυφή του. */
        align-content: center;
    }

    /* Η δεύτερη σειρά παίρνει το ίδιο ύψος με την πρώτη, ώστε το άθροισμα να
       είναι ακριβώς αυτό που δεσμεύτηκε παραπάνω. */
    [data-kpi-grid]:has(.kpi-tray-row > .kpi-subrow) .kpi-tray-row > .kpi-subrow {
        min-height: 24px;
    }
}
