Consume an ASCII run in fitEnd instead of asking twice per character

`fitEnd` decides where a wrapped row breaks, and it asked two function calls per
character to learn what arithmetic knows. `modal.nextGrapheme` and
`graphemeDisplayWidth` each already answer ASCII in constant time - that was earlier
work - but they answer once per character, and a 640-column line asks 640 times.

A printable ASCII byte whose successor is also ASCII is a complete grapheme cluster one
column wide. That is the same guard, for the same reason, as the three fast paths already
in `Surface.print`, `modal.nextGrapheme` and `graphemeDisplayWidth`: every rule that
could join an ASCII base into a longer cluster - Extend, ZWJ, SpacingMark, Prepend,
Regional_Indicator - is spelled with non-ASCII scalars. Tabs and the C0 controls are
excluded by the range test and keep the general path, as does anything wide.

Measured on the die: 21 us of a 640-character keystroke, 5 us at 160. Small, and reported
as small - the interesting part is that it is small, because it says the per-character
grapheme walk was NOT where a long line's cost lives.

The test pins the fast path to the general walk it replaces rather than to transcribed
expectations: same inputs through both routes, every start offset, every width from zero
to past the end, over strings chosen to land the boundary inside a combining sequence, a
wide glyph, a regional-indicator pair, a tab and a CR. A break that moved by one column
would move text on screen, so this is the invariant worth holding.

0 files changed, 0 insertions, 0 deletions