clamp startIndex in subString to avoid unsigned length underflow

[zayeem06]

subString8 and subStringUTF16 only clamp the upper index and then compute the copy length as endIndex - startIndex in unsigned arithmetic, so a call where startIndex is past endIndex (for example subString(s, 6, 5)) wraps the length to roughly 0xFFFFFFFF. That value reaches newPtr8/newSize8 where size + 1 overflows to 0, so a minimal buffer is allocated and the following memmove copies about 4GB, which AddressSanitizer flags as a heap overflow at newPtr8. subString is a public string method that generated parsers and grammar actions use to slice token text with offsets derived from the input, so reversed offsets are reachable. The fix clamps startIndex to endIndex in both functions so the subtraction can no longer underflow. Reviewers may want to confirm that ordinary substrings are untouched, which they are since the guard only fires when startIndex already exceeds endIndex.