Count unpaired carriage returns in adjustForLineEnding

[sahvx655-wq]

adjustForLineEnding subtracts one character for every CR and every LF it counts, but adds lineEndLength back only once per LF, so it quietly assumes every carriage return arrives paired with a line feed. I went looking after noticing the two lineEndLength overloads have no coverage beyond the single "12345\n\r" fixture, and an unpaired CR turns out to contribute zero to the adjusted length: maxLength("12345\r", 5, 1) returns true where the adjusted length is 6, and maxLength("\r\r\r\r\r", 1, 2) returns true because a CR-only value adjusts to 0 no matter how long it is. A client picks its own line endings in a submitted textarea and nothing normalises them beforehand, so a field can be pushed past a declared maximum by an unbounded number of carriage returns; minLength mirrors it and wrongly rejects minLength("12345\r", 7, 2), whose adjusted length is exactly 7.

Taking the line-ending count as the greater of the two counters rather than the LF count alone is enough, since the number of line endings is bounded below by the CR count and by the LF count. Keeping it in the private helper corrects both public overloads in one place rather than leaving each caller to normalise first, and the paired CRLF and LF-only forms compute exactly as they did, so the existing testMaxLength and testMinLength expectations are untouched. I have deliberately left the reversed "\n\r" sequence counting as one line ending, which is what those tests pin down today; the added regression covers the unpaired carriage return only and fails without the runtime change.

Before you push a pull request, review this list:

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.