Three bugs in the async version of UnpWriteBuf (used only in the async
decompression path) were causing data corruption when decompressing RAR5
archives containing executable filters (E8/E8E9/ARM) whose blocks spanned
the 4MB write boundary (UNPACK_MAX_WRITE):
1. WrittenFileSize was only incremented inside `if (OutMem != null)`, but
should always be incremented after ApplyFilter (matching sync behavior).
2. UnpSomeRead = true was missing from the filter processing path.
3. In the NotAllFiltersProcessed else branch (filter intersects write border):
- WrPtr was not updated to WrittenBorder, corrupting the window pointer
used to compute WriteBorder on the next flush cycle
- Remaining filters had NextWindow set to true (inverted logic), when
sync correctly sets them to false so they are processed next time
All three changes align the async path with the sync UnpWriteBuf logic.
- Updated SharpCompress.csproj target frameworks from net48;net481;netstandard2.0;net6.0;net8.0 to net48;net481;netstandard2.0;net8.0;net10.0
- Updated test and build projects to use .NET 10
- Updated global.json to .NET 10 SDK
- Updated CI workflow to use .NET 10
- Fixed deprecated Rfc2898DeriveBytes constructor for .NET 10 (SYSLIB0060)
- Updated package description and README to reflect new supported frameworks
- Updated package versions for .NET 10 compatibility
Co-authored-by: adamhathcock <527620+adamhathcock@users.noreply.github.com>
