/* Metric-matched stand-in for "Nazli", so the font-display:swap changes the
   letterforms and nothing else — no reflow, no jump, no CLS.

   Without it the first paint uses whatever generic the chain lands on, the real
   face arrives with a very different line box, and every line in the answer
   re-wraps under the reader's eye. chat-canvas.css spends its whole CLS budget
   on KaTeX reflow; a font swap must not borrow from it. This face has more work
   to do than the last one did: Nazli sets the same Persian sentence 27% shorter
   than Tahoma, so an unadjusted fallback would be wildly wider than the real
   thing.

   Every number MEASURED, in the engine that has to honour it, with
   live/tools/_font_metrics_probe.js — canvas TextMetrics
   fontBoundingBoxAscent/Descent at 1em = 1000px, plus the advance of one real
   product sentence at 100px:

     Nazli    ascent 95.70%   descent 54.40%   sentence 2852.05px
     Tahoma   ascent 100.00%  descent 20.70%   sentence 3911.04px

     size-adjust      = 2852.05 / 3911.04           = 72.92%
     ascent-override  = 95.70% / 0.7292             = 131.23%
     descent-override = 54.40% / 0.7292             =  74.60%

   The division by size-adjust is not optional: size-adjust scales every metric
   of this face, while the override percentages resolve against the SPECIFIED
   font-size. Skipping it is the classic off-by-8% in a fallback face.

   Why the engine and not the font tables: whether a line box comes from hhea or
   OS/2 depends on the USE_TYPO_METRICS bit, and only the engine knows which it
   took. The probe was validated before it was trusted — run against Vazirmatn
   RD it returns 102.50% / 53.70%, against the 102.54% / 53.71% a WOFF2 table
   parser read out of that font's own tables in an earlier pass. A method that
   reproduces a known answer can be believed on a new one.

   Tuned to Tahoma, which is on every Windows install and is listed first.

   THE GAP, NAMED RATHER THAN LEFT TO BE REDISCOVERED
   On Android and iOS neither local() resolves, so this face never loads there
   and those readers get no CLS protection at all — the first paint uses a
   system generic with quite different metrics and the text reflows when Nazli
   arrives. That was tolerable while the product was a website people opened on
   a phone. It stops being tolerable when the platform ships as a mobile web
   app, which is the stated direction, because an app is judged on the first
   second and a reflowing first paint is the most visible thing in it.

   Fixing it properly means a SECOND fallback family listed after this one in
   --nbgc-font, tuned to a face those systems actually have: Android carries
   Noto Naskh Arabic (and Droid Arabic Naskh on older builds), iOS carries
   Geeza Pro. It has to be a separate @font-face because size-adjust,
   ascent-override and descent-override are per-face — one rule cannot be
   correct for Tahoma and for Geeza Pro at the same time, and a single face
   listing several local() sources would apply Tahoma's numbers to whichever
   one actually resolved. That is worse than no adjustment.

   The numbers are deliberately NOT guessed here. live/tools/_font_metrics_probe.js
   produces them in one run, but it has to run on a machine that HAS the face —
   this one is Windows and has neither. Run it on the target device (or a
   matching emulator), take size-adjust / ascent-override / descent-override for
   Noto Naskh Arabic and Geeza Pro, and add the second family then. Inventing
   the three numbers here would ship a fallback that is confidently wrong, which
   is exactly the failure this file was written to prevent. */
@font-face {
  font-family: "Nazli Fallback";
  src: local("Tahoma"), local("Segoe UI");
  size-adjust: 72.92%;
  ascent-override: 131.23%;
  descent-override: 74.60%;
  line-gap-override: 0%;
  font-weight: 400 700;
  font-style: normal;
}