Firefox logged one warning per glyph, on every page load, for every Font Awesome
file WeKan serves:

downloadable font: glyf: Glyph bbox was incorrect; adjusting (glyph 19)
(font-family: "Font Awesome 6 Free" ...) source: .../fa-regular-400.woff2

819 of the 2163 glyphs were affected - 540 in fa-solid-900, 204 in
fa-brands-400, 59 in fa-regular-400, 16 in fa-v4compatibility - so the
console filled with hundreds of lines and stopped being useful for spotting
anything else.

Every TrueType glyph stores its own bounding box in the glyf table. Font
Awesome ships boxes that are TIGHTER than the outline: they bound the on-curve
points only, while the box has to bound the control points too, because a
quadratic curve can bulge past its endpoints. Firefox's OpenType sanitiser
notices, corrects each box in memory and says so. Nothing rendered wrongly - the
warning was the whole of the damage - but the numbers in the file were wrong,
and they are wrong upstream, in Font Awesome's own build.

releases/fix-font-bboxes.py recomputes them, and writes the .ttf and the
.woff2 from one corrected font so the pair cannot drift. Only head and
hhea differ from what Font Awesome shipped, and both follow from the boxes;
every other table compiles identically, which the script verifies by reading
back what it wrote. It keeps Font Awesome's own head.modified, so two runs
over the same input agree byte for byte rather than churning a committed binary.

tests/fontGlyphBounds.test.cjs parses the fonts with its own reader rather
than the tool that wrote them, and that guard matters more than the fix: these
fonts are VENDORED, so the next Font Awesome upgrade drops fresh upstream files
straight back into the tree and the warnings would return silently, months from
anything that would explain them. The failure message names the script to
re-run.