numfmt: report oversized --padding instead of aborting

[leeewee]

Fixes #12560.

Problem

A large --padding makes pad_string (added to handle widths beyond
format!'s u16 cap) call String::with_capacity(width) with an unbounded,
user-controlled width, crashing the process:

$ numfmt --padding=9000000000000000000 1
memory allocation of 9000000000000000000 bytes failed
Aborted (core dumped)            # exit 134

$ numfmt --padding=-9223372036854775808 1
thread 'main' panicked at .../alloc/src/string.rs: capacity overflow
Aborted (core dumped)            # exit 134

(-9223372036854775808 is isize::MIN; its magnitude is isize::MAX + 1,
which overflows with_capacity's capacity check deterministically.)

GNU reports this cleanly and exits 1:

$ numfmt --padding=9000000000000000000 1
numfmt: memory exhausted         # exit 1

Fix

Validate the padding up front in uumain — before reading any input — with a
fallible try_reserve_exact, and fail with memory exhausted (exit 1) on
overflow/allocation failure.

Doing the check up front (rather than lazily inside pad_string) also matches
GNU's observable behavior:

• it fails immediately and does not block on stdin
  (numfmt --padding=-9223372036854775808 no longer waits for input);
• it does not silently exit 0 when there is no input.

memory exhausted is surfaced as NumfmtError::IoError, which exits 1 —
consistent with how uutils numfmt already matches GNU's other exit codes
(option errors → 1, input-conversion errors → 2).

Tests

Added test_padding_too_large_fails_cleanly. Full numfmt suite passes
(152 integration + unit tests); cargo fmt/clippy clean.

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/tail/tail-n0f (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/seq/seq-epipe is now being skipped but was previously passing.

[leeewee]

All done — addressed all three comments.