Automatically rewind base stream position when DeflateStream decompression finishes

[iremyux]

Fixes automatic stream positioning issue when using compression streams with mixed-content data.

When using DeflateStream, GZipStream, or ZLibStream for decompression, the underlying stream position would advance past the end of compressed data due to internal buffering. This caused issues when reading additional content after decompression in mixed-format files.

Fixes #73770

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull Request Overview

This PR fixes an issue where DeflateStream, GZipStream, and ZLibStream would leave the underlying stream position past the end of compressed data due to internal buffering, making it impossible to read additional content after decompression in mixed-format files.

Key Changes:

• Added automatic stream rewinding logic that repositions seekable streams to the exact end of compressed data when decompression finishes
• Exposed internal method GetAvailableInput() in Inflater to track unconsumed buffered bytes
• Added comprehensive test coverage for both sync and async decompression scenarios

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
CompressionStreamUnitTests.Deflate.cs	Added two test methods (AutomaticStreamRewinds_WhenDecompressionFinishes and async variant) to verify stream position is correctly restored after decompression
Inflater.cs	Added GetAvailableInput() method to expose the count of unconsumed bytes in the internal buffer
DeflateStream.cs	Implemented automatic stream rewinding in both Dispose and DisposeAsync by seeking backwards by the number of unconsumed bytes