Add extraction benchmarks and fix per-entry temp file spilling

[gfs]

Closes #208 (as measured, not as reported).

Issue #208 claims RecursiveExtractor is slow and blames Extractor.AreIdentical doing a full content compare. I didn't want to guess, so this adds a BenchmarkDotNet project to measure it — and then fixes the real problem the measurements exposed, which turned out to be something else entirely.

The benchmarks

New RecursiveExtractor.Benchmarks project. It compares RecursiveExtractor against raw SharpCompress on identical in-memory archives, isolates the quine check and type detection so their share of runtime can be read directly, and spreads the same payload across zip (stored and deflate), tar, tar.gz, tar.bz2 and 7z. All archives are generated at setup time by SyntheticArchives, so nothing depends on the test project's assets.

dotnet run -c Release -f net8.0 --project RecursiveExtractor.Benchmarks -- --filter "*" --job short

Findings

On a 1000 entry × 4 KiB deflate zip (ShortRun, net8.0):

	Mean	vs raw reader
SharpCompress: decompress only	27.0 ms	1.00
SharpCompress: decompress + buffer	26.7 ms	0.99
RE: Extract (recurse)	29.5 ms	1.10
RE: IsQuine over all 1000 entries	21 µs	0.001
RE: DetectFileType over all 1000 entries	356 µs	0.013

• The quine check is not the problem. ~20 µs with zero allocations across 1000 entries — about 0.06% of extraction. AreIdentical compares Length and Name before it ever looks at bytes, so the full content compare only runs when an ancestor has both the same size and the same name. Removing it would save nothing and would lose the zip bomb protection that dependent scanners rely on.
• Type detection is ~1%.
• RecursiveExtractor's own overhead is ~10–20% over a raw reader doing the same buffering. The rest is the format library, which matches the expectation.
• The container dominates. Same 200 × 8 KiB payload: ~0.3 ms stored zip → ~9 ms deflate zip → ~100 ms tar.bz2.
• ExtractorOptions.Parallel already gives ~1.8× on ExtractToDirectory (500 entries: 421 ms → 245 ms), which covers the second half of the issue.

The bug the benchmarks found

ExtractAsync was ~28× slower than Extract for zip.

StreamFactory.GenerateAppropriateBackingStream(int?, Stream, int) reads targetStream.Length inside a try, and on any exception returns a delete-on-close FileStream. That treats "I can't determine the size" as "assume it's huge". SharpCompress entry streams can't seek and always throw, so this fired on every entry, writing each one to a temporary file on disk.

Two paths hit it:

• ZipExtractor's async path passed the raw entry stream (3 call sites), while the sync path had always passed zipEntry.Size.
• 7z / Rar / Ace / Arj / Arc / Xz pass a non-seekable entry.OpenEntryStream() straight into FileEntry, landing in the same fallback from the constructor.

Fix

1. ZipExtractor passes the size it already has (zipEntry.Size / forwardReader.Entry.Size) — the value is literally on the preceding CheckResourceGovernor line.
2. The unknown-length fallback now returns a new internal SpillOverStream: buffers in memory and moves to a delete-on-close FileStream only if the content actually exceeds MemoryStreamCutoff. This keeps the memory guard intact, fixes every extractor at once, and needs no public API change.

Benchmark	Before	After
ExtractAsync, 1000 × 4 KiB zip	930 ms	38 ms	24.8×
ExtractAsync, 100 × 4 KiB zip	100 ms	3.1 ms	32.6×
7z, 200 × 8 KiB	320 ms	53 ms	6.1×

Testing

• 8 new tests in RecursiveExtractor.Tests/StreamFactoryTests.cs covering the memory/disk decision, the spill transition, content integrity across the transition, the async and byte-at-a-time write paths, SetLength, and the null-cutoff opt-out.
• Full suite green: 685 tests on net8.0, 648 on net48 (the netstandard2.0 path).

Not addressed here

• 7z still allocates ~26× the baseline. That looks like SharpCompress rebuilding the LZMA decoder for each entry.OpenEntryStream() rather than anything in this repo — worth a separate look.
• Absolute numbers above are from a Hyper-V VM and are noisy; the Ratio columns are the reliable part.