split --number={N,K/N,l/N,l/K/N} rejects piped input that GNU 9.2+ accepts with "cannot determine input size"

GNU coreutils 9.2 changed split -n to accept non-seekable input by first copying it to a temporary file.

uutils still implements the pre-9.2 behavior: get_input_size() probes stdin up to sane_blksize and errors if EOF isn't reached

Hence, any pipe >= 512 bytes fails while GNU succeeds. The boundary is 512 bytes because sane_blksize_from_path(Path::new("-")) stats the literal path -, which fails and falls back to DEFAULT = 512.

Current behavior (uutils 0.8.0 and main)

seq 500 | split -n l/1/4
split: -: cannot determine input size

Expected behavior (GNU coreutils 9.5)

seq 500 | split -n l/1/4
1
2
3
...
146

I saw that the current behavior is asserted in test_split.rs (test_split_number_oversized_stdin), so this is deliberate but since this repository aims at drop-in compatibility, I guess the two implementations should remain aligned on that. Maybe, this repository could also use a tmp file as done in the GNU implementation ?

(Found via a CI regression in AppArmor. Our container image is based on ubuntu:latest, whose coreutils is uutils since 25.10 in https://gitlab.com/apparmor/apparmor/-/merge_requests/2166)

Start with the split implementation's get_input_size() path and the test_split.rs test_split_number_oversized_stdin test. Compare how piped input is handled for split -n l/1/4, then verify that inputs larger than the current 512-byte probe work without the cannot determine input size error. Done means the relevant test passes and piped behavior matches the stated GNU output expectations.