Stop a broken string from being read one byte at a time - #7131

A search under mruby-regexp refuses a subject whose bytes are not UTF-8
(mruby#7126), and what an unwalked subject pays there is one walk. The walk's
answer is remembered on the string it read, and mruby#7131 lets a string
already known ASCII answer without one, but the operations a subject is
usually built with still dropped what their sources knew: `+` copied no
flags at all, `<<` and interpolation took them down on every append, and
a piece cut out of a walked string kept only the single-byte mark. So
the subject of `(mb + "z") =~ /z/` walked 300001 bytes per search,
300000 of which a walk had already read.

Validity survives every one of those builds, each for a reason the build
can afford to check:

- Concatenation: bytes that read as UTF-8 followed by bytes that do read
  as UTF-8 end to end, each side's sequences being complete on their
  own. `+`, `<<`, `concat` and interpolation hand the result the flag
  when both sides carry it, and two ASCII sides make an ASCII whole,
  which carries MRB_STR_SINGLE_BYTE the same way. An empty side carries
  both by holding nothing.

- Repetition: `str * n` holds nothing but the source's bytes over and
  over, so the source's answer is the result's.

- A byte range: a range of a valid string reads whole exactly when both
  cuts land on character boundaries, and in a valid string every byte
  that is not a continuation byte begins a character. So the byte each
  cut lands on decides it--the one at `beg`, and the one just past the
  range, with the end of the string standing for a boundary--in two byte
  tests, no walk. This is what hands a searched subject's flag down to
  the pieces `split`, `scan` and `byteslice` cut from it.

- Measuring: past the ASCII run the count now returns early on, it
  decodes every sequence anyway, so the same walk also says whether each
  spelled a character, and leaves that answer where the next search
  finds it. A stray byte still counts as one character, which is the
  count this has always returned.

What would defeat the hand-off is the short literal nothing has walked:
the "z" above arrives from the pool flagless on every evaluation, and
one flagless side spoils the pair. So a side of at most 16 bytes is
walked on the spot--all-ASCII answers in a word test--bounded by the
length check and below the cost of the copy its caller is doing anyway.
That is what lets `mb + "z"`, `"#{mb}z"` and the `"あ" * 100000` that
built `mb` come out flagged. The answer is not written back to the
walked side: it is most often a literal this evaluation made and the
next one remakes, so there is no later read to save a walk for, and
re-walking a reused one costs these same few bytes.

The flag never claims more than a walk of the same bytes would find, so
no answer changes. The test that puts the same bytes through the same
operations warm and cold now runs the new builders too, over broken
bases as well as whole ones, and a new block pins the boundary-byte
cases where a cut must not inherit.

At `-O3` on a full-core build, the fastest of seven runs interleaved
between builds, with `mb = "あ" * 100000`:

| | master | with this |
|---|---|---|
| `(mb + "z") =~ /z/`, 200 times, less the builds | 178.2 ms | 96.1 ms |
| `"#{mb}z" =~ /z/`, the same | 195.3 ms | 111.9 ms |
| `"hello world" =~ /world/`, 100000 times | 235.0 ms | 242.0 ms |
| `s << "abcdefgh"`, 100000 times, never searched | 15.1 ms | 16.1 ms |

The first two land where they stood before mruby#7126 made subjects
checkable at all (96.3 ms and 113.7 ms on the same machine): nothing
walks but the "z". Pieces split off a walked subject stop paying their
own first walk the same way. The last row is the cost's worst case, a
loop of nothing but eight-byte appends to a buffer that stays
known-valid, where the flag reads are around a third of the growth and
the bounded walk the rest; it moved six to twelve percent across
measurement rounds here. A loop appending sides longer than the bound
does not walk them, and one whose buffer was never known valid drops to
the flag tests alone. `split`, `gsub`, `rindex`, the third row and
String#length move a few percent either way between rounds, with no
changed code on their paths--the jitter code layout pays for this
file growing.

A literal born flagged would close the walk of the "z" too, but the
pool entry has no bit left to carry the answer in (IREP_TT_STR spends
them all), and stamping it at OP_STRING would only move the same walk
there. That is a dump-format question for another day.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T6X4dd382CCZmfrXSpFsb8