Ground-truth backstop: after render, no note's glyph (head, stem, accidental, or modifier) may extend past the stave's own drawn end-barline position

This is the irreducible, final check beneath every prediction rule in this chapter: whatever the pre-render formula predicts, whatever VexFlow's Formatter decides, the one fact that actually matters to a reader is whether content visibly ran past the barline or off the printed page — a rendered-SVG geometry probe against the ACTUAL drawn stave boundary is the only check that can never be fooled by an error anywhere upstream in the prediction chain.

No such check exists anywhere in Gradus today. Every other rule in this chapter is a PREDICTION (will this overflow?) computed before or independent of the real render; none of them confirm what the render ACTUALLY produced. Given that `formatW`/`staveW` (lines 829-831) is an estimate, and the Formatter's own fallback path (line 1143) uses a different, magic-number margin than the upstream estimate, there is a real possibility that even after all the fixes in this chapter land, some content still overflows for a reason no static model anticipated (an unusual VexFlow internal decision, a future glyph type, a font substitution) — and nothing today would catch that in CI.

This is the direct mechanization of 'never let notes pass the barline' as stated in Sean's own brief and echoed by every authority cited in this chapter (Ross, Gould, Read) as the thing all their spacing rules exist to prevent — it is a geometry check, not a citation to a specific engraving rule beyond the universal one.

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