A short read is not the end of the stream

[redbluevn]

Stream.Read is allowed to return fewer bytes than asked for, and StreamIO treated a short read as the end of the stream. Three places acted on that assumption:

• ReadBytes / ReadBytesAsync threw EndOfStreamException whenever one call came back short, even with the data still sitting in the stream. They now loop until the buffer is full and throw only on a genuine zero-byte read. ReadAsync is the one that makes this reachable in ordinary use — a network or compressed stream frequently returns less than asked.
• The buffering constructor read a non-seekable stream by asking for stream.Length — a property a non-seekable stream is entitled to throw on — and then read it in a single call, keeping whatever that call happened to return. It now uses CopyTo, and only touches Position on a stream that can seek.
• GetBytes, GetBytesAsync and LookBytes restored the caller's position after the read, so a read that threw left the object parked at the requested offset. The restore is in a finally now.

Three tests, all of which fail on master and pass here:

test	what it pins
ReadBytesCompletesPartialReads	a stream that returns two bytes per call still yields the whole buffer
ReadBytesAsyncCompletesPartialReads	the same on the async path
ConstructorBuffersANonSeekablePartialReadStream	a non-seekable stream is buffered without asking for Length

Suite: 143 passed / 0 failed on net9.0 and net48. Reverting only StreamIO.cs and keeping the tests gives exactly 3 failures, so the tests measure the fix rather than the code around it.

Found while reading DWG files through ACadSharp, where StreamIO sits under the section readers.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Tw5VCqpDMFiQZ67K3rQ1eB