Augmentation dots must add horizontal width in the PRE-RENDER estimate, not just at VexFlow draw time

A dot sits to the right of a notehead and consumes its own small but nonzero width; dotted rhythms are common enough in Gradus's chorale and hymn-tune content that omitting dot width from the pre-render estimate systematically under-predicts required width for exactly the material most likely to need wrapping.

`Dot.buildAndAttach([sn])` (line 1012) is called once per dot at DRAW time and VexFlow's real Formatter accounts for it there — but the pre-render `formatW` (line 829), used to CHOOSE `beatW`/`staveW` before the Formatter ever runs, has no dot term. A system that is mostly dotted rhythms will have its `beatW` chosen as if every note were plain, then the real Formatter has to squeeze the dots in afterward.

Ross, The Art of Music Engraving (dot spacing enumerated alongside notehead and accidental spacing); Gould, Behind Bars (dot placement, including the rule that a dot on a line-note shifts to the adjacent space); SMuFL/Bravura `augmentationDot` glyph metrics measured directly from Gradus's own font dependency.

This rule can be decided from pitches, durations and voices — no layout required. A validator can check it before anything is drawn.