require three ASCII digits for the response status code

[basavaraj-sm05]

StatusLine.parse pulls the three response-code characters out of the status line and hands them to toIntOrNull() to get the numeric code. That delegate does more than read ASCII digits: it accepts a leading + or - sign, and because it resolves each character through Character.digit it also accepts any Unicode decimal digit, so an Arabic-Indic "٢٠٠" comes back as 200 and "+99" as 99. RFC 9112 defines status-code as exactly three ASCII DIGIT, and the value here comes straight off the wire, whether from an HTTP/1 status line, an HTTP/2 :status pseudo-header (Http2ExchangeCodec builds "HTTP/1.1 $value" from it), or a cached response, so a hostile or non-conforming server can hand okhttp a code that a conforming proxy or log sitting in front of it reads differently. A "-12" even parses to a negative code that only trips a check much later when the Response is built. I noticed it while adding cases to the existing nonThreeDigitCode test, which only covered letters and wrong lengths. Restricting the three characters to '0'..'9' before converting keeps every valid code working and rejects the rest at the parser.

[JakeWharton]

This makes multiple passes and allocations. If we're going to modify this code, we should also improve its performance by not creating the substring and operating directly on chars/doing the trivial math ourselves.

[basavaraj-sm05]

Done. It now walks the three chars once, checking each is in '0'..'9' and accumulating the code in the same loop, so the substring and the extra pass are both gone.