Remove duplicated surrogate-pair start adjustment in StringUtils.mid()

[java-dependency-upgrade-fixer]

Context

Mirrors upstream apache/commons-lang PR apache#1776 (StringUtils.left/right/mid/overlay stay off surrogate-pair boundaries), as re-proposed at head 164ab3a against base e66ad3d.

Change

In StringUtils.mid(String, int, int), the surrogate-pair-safe start computation (int start = pos; if (splitsSurrogatePair(str, start)) start++;) was duplicated verbatim in both the early-return branch and the general branch, even though it only depends on str and pos, which are identical in both branches. This companion hoists the computation once above the branch; the end adjustment remains only where end is computed.

Why it's safe

• Both branches previously executed the exact same start-adjustment logic on the exact same inputs (str, pos); moving it above the branch changes nothing observable.
• The PR's own exhaustive characterization tests (testMidSurrogatePairs style fuzzing over every pos/len combination for a string mixing surrogate pairs and plain chars) pass identically before and after: 194 focused tests, 0 failures, 0 errors, 1 pre-existing skip.
• Full repository build (tests, Checkstyle, SpotBugs, PMD, japicmp, Javadoc) is unchanged and green: 89203 tests, 0 failures, 0 Checkstyle violations, no SpotBugs/PMD/japicmp findings.

What was evaluated and not changed

• left(), right(), and overlay() already contain minimal, non-duplicated logic; no safe simplification was found.
• Introducing a shared private helper for the repeated splitsSurrogatePair adjustment pattern across left/right/mid/overlay was considered and rejected: the same inline pattern already exists in unrelated pre-existing methods (abbreviate, abbreviateMiddle, chop, substring) outside this PR's changed scope, so a shared helper would either create inconsistency with those methods or require an unrelated, unbounded refactor.
• No performance optimization applies: the added check is O(1) and this edit only removes a duplicate O(1) check, not an algorithmic hot path.
• No build/dependency/version file is touched by this PR, so modernization is not applicable.

Limitations

This is a bounded 4-line cleanup inside one already-changed method. It does not add new test coverage beyond what the original PR already provides, since the existing tests already exhaustively fuzz mid() across pos/len space and are sufficient to lock this method's behavior.

---

Generated by JAIPilot Cloud for #1 from Anthropic session sesn_01WcsYEJ69Kx3ubEWJ5bn7Jx.