Reject non-ASCII hex digits in isValidInet6Address

[sahvx655-wq]

isValidInet6Address splits the address on ':' and hands each hex group straight to Integer.parseInt(octet, 16). That parser is more permissive than an IPv6 group should be: it delegates to Character.digit, which maps non-ASCII Unicode digits to 0-15, so a group written with fullwidth digits (U+FF10-FF19) or Arabic-Indic digits (U+0660-0669) parses cleanly and slips through the length and range checks. The result is that addresses such as the fullwidth "1234::" are reported as valid IPv6 addresses even though java.net.InetAddress and every real resolver reject them. The same gap is reachable through EmailValidator (bracketed IPv6 domain) and the UrlValidator authority, so a caller relying on this for a host allowlist can be fed a value that validates here but resolves elsewhere. The IPv4 path is unaffected because its regex \d only matches ASCII digits.

The existing guard already rejected a leading sign for the same reason (Integer.parseInt tolerating input that is not a real group). I have widened that single check into a per-character test that accepts only [0-9A-Fa-f], which covers the sign case and the non-ASCII digits in one place rather than enumerating each offending form. Keeping the check next to the parse means the rule stays where the value is actually consumed. Added regression tests alongside the existing signed-group cases.