`Version.parsed()` throws `NumberFormatException` for numeric component exceeding `Integer.MAX_VALUE`

What happens

Version.parsed() first accepts arbitrary-length decimal components with \d+, then stores each component in an int with Integer.parseInt():

private static final Pattern CORE = Pattern.compile("^(\\d+)\\.(\\d+)\\.(\\d+)");
...
new Version(
    Integer.parseInt(matcher.group(1)),
    Integer.parseInt(matcher.group(2)),
    Integer.parseInt(matcher.group(3))
)

On current master 91ff81b80f0918d1e01846f289ead22dc58ad3e0, an otherwise numeric version whose component exceeds Integer.MAX_VALUE passes the regex and escapes the parser as a bare NumberFormatException.

I compiled the current Version.java together with a same-package harness and got:

1.2.3 -> Optional[1.2.3]
999999999999999999999999.2.3 -> THREW java.lang.NumberFormatException: For input string: "999999999999999999999999"
1.999999999999999999999999.3 -> THREW java.lang.NumberFormatException: For input string: "999999999999999999999999"

Why this is a problem

Version.parsed(String) returns Optional<Version> and its current callers treat an unparseable/non-SemVer value as Optional.empty(). LtSyntaxVersion, for example, explicitly documents that non-SemVer values are ignored rather than crashing the lint run. An oversized numeric +syntax value is syntactically matched as a version core but instead aborts linting with an implementation-level integer conversion exception.

This makes the behavior depend on the magnitude of the digits rather than on whether the version is parseable under the lint's contract.

What should happen

An overflowing numeric component should be handled as an unparseable version (return Optional.empty()), or Version should use a representation that can safely compare the accepted numeric range. In either case, malformed/oversized metadata should not leak a bare NumberFormatException out of Version.parsed().

I searched the open issues for Version parsed NumberFormatException, syntax-version overflow, huge syntax version, integer overflow version, and related wording and found no duplicate.

Start with Version.java, focusing on Version.parsed() and the Integer.parseInt() calls described in the issue, then inspect the LtSyntaxVersion caller and its handling of Optional.empty(). Reproduce the oversized-component examples from the issue and add regression coverage; done means malformed or overflowing version metadata no longer leaks NumberFormatException and follows the parser's unparseable-version behavior.