`LineOf` allows numeric `@line` values exceeding `int` range resulting in `NumberFormatException`

What happens

The fix for non-numeric @line values made LineOf.value() check line.matches("\\d+") before parsing, but a numeric value can still exceed Java's int range and escape as the same bare NumberFormatException.

Current master 91ff81b80f0918d1e01846f289ead22dc58ad3e0:

final String line = this.element.attribute("line").text().orElse("0");
final int result;
if (line.matches("\\d+")) {
    result = Integer.parseInt(line);
} else {
    result = 0;
}

A minimal Java reproduction of that exact branch:

7 -> 7
abc -> 0
999999999999999999999999 -> THREW java.lang.NumberFormatException: For input string: "999999999999999999999999"

Why it matters

LineOf explicitly promises line 0 when the attribute is "missing or not an integer". A decimal string outside the representable int range is not a valid integer for this API, yet it passes the regex and terminates lint analysis with an implementation-level conversion exception.

This is distinct from #1387: that report covered non-numeric values such as line="abc", and current master now handles those. The remaining failure is numeric overflow after the new regex gate.

Broken/hand-written XMIR is precisely where defensive line parsing matters; the linter should report defects rather than crash while trying to read their location.

What should happen

Catch overflow and fall back to 0, or parse through a safe helper that returns 0 for any value that cannot be represented as a line number.

A regression in LineOfTest should cover a numeric string larger than Integer.MAX_VALUE and assert that value() returns 0 without throwing.

I searched issues for LineOf overflow, LineOf large line, LineOf Integer.MAX_VALUE, numeric @line NumberFormatException, and huge line NumberFormatException; no duplicate was found.