The pre-render width estimate and VexFlow's real Formatter measurement are two independent computations that can disagree, and the disagreement itself must be checked

Any system that predicts required width BEFORE invoking the real layout engine, in order to make a layout DECISION (choosing `beatW`, choosing to wrap), must be validated against what the real layout engine actually produces — otherwise the decision can be made on a wrong basis and only discovered wrong after the fact, precisely the overflow bug this chapter addresses.

`formatW`/`fixedExtras`/`staveW` (lines 759-831) are computed using ONLY `maxBeats`, `maxNoteCount`, `keySigExtra`, and `barlineCount` — none of accidentals, dots, ledger lines, grace notes, ornaments, or dynamics. The REAL width VexFlow needs is measured separately by `fmt.formatToStave(sysVoices, narrowest)` (line 1141), which DOES account for all of that via VexFlow's own real measurement. These two numbers are NEVER compared anywhere in the code — if the Formatter needs more room than `staveW` provides, VexFlow will either compress notes tighter than the pre-chosen `beatW` intended, or produce visually crowded output within the fixed-width Stave the pre-render math already locked in (line 887).

Software-engineering principle grounded in the specific code read; the underlying engraving conventions it protects (accidental/dot/grace/ledger width) are the ones with external authority documented above.

This rule is about where marks land on the page, so it can only be judged after engraving. Collision and spacing faults live here.