/* ═══════════════════════════════════════════════════════════════════════════ AIMY RESPONSIVE — ONE UI SCALE THE MECHANISM IS `zoom` ON , and it is AiMY QA's (QA/assets/aimy-responsive.css), ported so the three products answer a wide screen the same way. Above the anchor the whole shell is scaled up proportionally, so a wider viewport shows the SAME layout — the same cards per row, the same proportions — physically larger, with no stretching and no browser zoom. BELOW THE ANCHOR IT DOES NOT SCALE AT ALL. It used to shrink to a 0.85 floor, which kept every column on a narrow screen by making the type on it smaller — a 1200px laptop read 11.9px body text where the reference build reads 14. Width is floored at 1 now and the breakpoints in this file, in sales.css and in bdr.css take the narrow range instead, each re-keyed to the layout width it was always written for. Height still scales, because a short window has nowhere to put the rows; the argument is at UI_MIN_SCALE in assets/aimy-viewport.js. THE ANCHOR IS 1536, and it lives in assets/aimy-viewport.js. 1536 is the CSS viewport a 1920 panel reports at Windows' default 125% display scaling — the width this app is actually looked at. Anchoring above the real viewport is what makes zooming out shrink the UI; the reasoning is written out in full next to UI_ANCHOR_W. WHY NOT px-to-rem, which is the route AiMY Knowledge took: converting the ~3,100 px literals in sales.css and aimy-ds.css cannot fix `body { height: 100vh }` or the ten other vw/vh sites, and cannot scale a `position: fixed` offset against a viewport that does not shrink — .aimy-float-wrap's `bottom: 20px` and .aimy-overlay's `top: var(--topbar-height)` would drift away from a scaled shell. `zoom` scales every property coherently. ── WHY THE SELECTORS ARE PREFIXED ───────────────────────────────────────── Sales carries no inline