string.c: ask a broken string again after String#reverse! - #7226

Follow-up to #7224, which put mrb_str_reverse_bang() on str_modify_keep_cr().
That helper keeps what the string is read as and asks a string read as broken
again:

/* src/string.c */
static void
str_modify_keep_cr(mrb_state *mrb, struct RString *s)
{
  mrb_check_frozen(mrb, s);
  str_unshare_buffer(mrb, s);
  if (RSTR_CODERANGE(s) == MRB_STR_CODERANGE_BROKEN) {
    RSTR_CODERANGE_SET(s, MRB_STR_CODERANGE_UNKNOWN);
  }
}

The test that came with #7224 reverses a broken string and finds it broken
after, which is the same answer whether the helper asks again or not. Nothing
there says why the asking again is needed, and a reverse! that kept a broken
answer passes it.

The case that shows it

Reversal is the write that can mend as well as break. Bytes that spell nothing
where they stand can spell a character once they are turned around:

d = "\x80\xC2"        # a trailing byte, then a lead byte
d.valid_encoding?     #=> false
d.reverse!            # the same two bytes, now U+0080
d.valid_encoding?     #=> true

The first valid_encoding? is what the case turns on. It is what puts the
broken answer on the string, so a reverse! keeping it answers false for a
string that is now valid. Without that question the string reaches the reversal
with nothing recorded, the helper walks it afterwards either way, and both
readings agree.

Reversing the multi-byte string a second time comes with it, so the record is
carried across two writes rather than one, which is the loop #7224 was measured
on.

Against a mrb_str_reverse_bang() that prepares its write without the broken
check, both new assertions turn red in every build that indexes by character:

Fail: String#reverse! leaves what the bytes read as standing (mrbgems: mruby-encoding)

The comment

The comment at the top of the function said what the bytes read as is still
what they read as. That is the promise str_modify_keep_cr() asks of a caller,
not the whole of what happens here, since the broken string is the one it
cannot promise for. It now names that string and why reversing is what can
settle it either way.

Testing

build_config/ci/gcc-clang.rb and build_config/gcc-asan.rb, run per build so
the counts are attributable:

The binary tests pass 117 of 117 under ci/gcc-clang and 84 of 84 under
gcc-asan. src/string.c changes only in a comment, so no build moves by a
byte.

Environment

Summary by CodeRabbit

• Bug Fixes
  • Improved String#reverse! handling for invalid byte sequences.
  • Ensured reversing strings preserves complete UTF-8 characters and correctly restores validity when possible.
  • Added validation for reversed string bytes, length, and encoding status.