Fix tar archive enumeration after fully reading entry streams

[Copilot]

TarArchive.OpenArchive(stream) could stop yielding entries when callers iterated archive.Entries, fully read an entry via OpenEntryStream(), and moved on before disposing that stream. In practice, the shared tar stream could remain parked on entry padding, so the next header read started from the wrong offset.

• Behavior change

  • Update TarReadOnlySubStream to advance to the next tar header as soon as the current entry has been fully consumed.
  • Keep the existing disposal-based cleanup path for partially read entry streams.

• Why this matters

  • Enumeration no longer depends on callers disposing each entry stream before requesting the next archive entry.
  • This matches the expected sync IArchive usage pattern shown in the issue, where each file is read to EOF during iteration.

• Regression coverage

  • Add a tar archive test that:
    • writes multiple files plus a directory entry,
    • iterates archive.Entries,
    • opens and fully reads each file entry,
    • delays disposing those entry streams until after enumeration,
    • verifies all entries are still present.

using var archive = TarArchive.OpenArchive(stream);

foreach (var entry in archive.Entries)
{
    if (entry.IsDirectory)
        continue;

    var entryStream = entry.OpenEntryStream();
    entryStream.CopyTo(Stream.Null); // fully consume without immediate dispose
}

var count = archive.Entries.Count(); // now remains stable

[JohnCampionJr]

@adamhathcock any chance we can get this merged?

[adamhathcock]

@copilot add a TarReader and TarReaderAsync and TarArchiveAsync style tests to this PR

[Copilot]

@copilot add a TarReader and TarReaderAsync and TarArchiveAsync style tests to this PR

Added matching regression coverage in TarReaderTests, TarReaderAsyncTests, and TarArchiveAsyncTests in ee64868.

[adamhathcock]

Closing in favor of #1342

This fix got lost. I'll put it out shortly