Stems lengthen for notes requiring several ledger lines, by a formula, not by feel

As a notehead moves further from the staff, its stem lengthens beyond the standard octave so the far end still reaches meaningfully toward the staff.

A note several ledger lines out whose stem stops at the standard 3.5-space length instead of extending per the formula above — the primary, verified cause in Gradus specifically: `getStemExtension()` explicitly returns the UN-extended `super_stem_extension` whenever `stem_direction !== this.calculateOptimalStemDirection()` (stavenote.ts:1210-1211), i.e. whenever an explicit manually-computed `stem_direction` (which Gradus ALWAYS passes, per `unforced-stem-must-use-auto-stem-not-omitted-stem-direction`) disagrees with what VexFlow's own auto-calculation would have produced. Every note affected by the treble-pivot bug therefore ALSO loses its ledger-line extension.

Gould, Behind Bars; Ross, ch. on stem length, same guidance with a practical cap. Verified directly in VexFlow source: `StaveNote.getStemExtension` (stavenote.ts:1203-1238) computes `mid_line_distance` (the relevant extreme notehead's line-distance from `MIDDLE_LINE = 3`, using `maxLine` for a stem-up chord and `minLine` for stem-down — deliberately the note that determined the direction, not the far side, per VexFlow's own inline comment), then `lines_over_octave_from_mid_line = mid_line_distance - 3.5`.

This rule needs the notated content and the rendered result together — the score says what should happen, the page says whether it did.