[fixfon]

Fixes #15818

conv=unblock trimmed each read buffer as if it started on a record boundary. When a read ended inside a record, the rest of that record was written as a second line, and every later record in the buffer was shifted. With cbs=80 and the default 512-byte block size (512 is not a multiple of 80), ten 80-byte records came out as REC0 to REC6, then REC7, REC8 and REC9 each preceded by 48 spaces, then a stray empty line. Short reads from a pipe did the same.

Converter already keeps the record length across reads for conv=block. It now does the same for conv=unblock: it keeps the position in the current record and the trailing spaces not yet written, drops them only when the record is complete, and finish ends a last incomplete record with a newline. The pending spaces are written in pieces of PAD_CHUNK, so a huge cbs still does not allocate cbs bytes. The order of conversion for the three unblock modes is unchanged.

I added two unit tests in blocks.rs (a record and its trailing spaces split over several reads, and cbs=usize::MAX) and two tests in test_dd.rs (the default block size from the issue, and ibs=3 obs=3 including a conv=ascii case). The new tests fail on current main and pass with this change. cargo fmt, cargo clippy -p uu_dd --all-targets -- -D warnings, cargo test -p uu_dd and cargo test --test tests test_dd pass. Tested on macOS only.