split: arithmetic overflow (overflow-checks) on a huge `--numeric-suffixes`/`--hex-suffixes` start value

split auto-computes the suffix length from the suffix start value (--numeric-suffixes=N / --hex-suffixes=N) and the number of output chunks (-n/--number). The computation adds them as start as u64 + chunks with no range check.

https://github.com/uutils/coreutils/blob/21d4e9635b07a04f262cd8a5386f2987bca6cfef/src/uu/split/src/filenames.rs#L167-L168

https://github.com/uutils/coreutils/blob/21d4e9635b07a04f262cd8a5386f2987bca6cfef/src/uu/split/src/filenames.rs#L200-L204

A start value near u64::MAX makes that add overflow, panicking with attempt to add with overflow under -C overflow-checks (exit 134). GNU rejects an out-of-range start value without crashing.

$ split -n 5 --numeric-suffixes=18446744073709551615 /dev/null
thread 'main' panicked at src/uu/split/src/filenames.rs:202:36:
attempt to add with overflow
$ echo $?
134

--hex-suffixes reaches the same add — but its value is parsed in base 16 (usize::from_str_radix(opt, 16)), so use a hex start near u64::MAX (0xFFFFFFFFFFFFFFFF):

$ split -n 5 --hex-suffixes=ffffffffffffffff /dev/null
thread 'main' panicked at src/uu/split/src/filenames.rs:202:36:
attempt to add with overflow
$ echo $?
134

The chunk count operand overflows the same add just as well — a huge -n with any nonzero start:

$ split -n 18446744073709551615 --numeric-suffixes=5 /dev/null
thread 'main' panicked at src/uu/split/src/filenames.rs:202:36:
attempt to add with overflow
$ echo $?
134

Start in src/uu/split/src/filenames.rs at the reported additions around lines 167-168 and 200-204, and reproduce the numeric, hexadecimal, and huge chunk-count examples. Ensure out-of-range values are rejected without an arithmetic-overflow panic, matching the GNU behavior described in the issue.