Allow decoding of blocks in parallel

[leonardehrenfried]

This adds parallel file block reader which decodes the zip stream in parallel but still delivers the decoded data as a single stream.

This makes it possible to use multiple threads to speed up decoding.

[simon04]

Claude Code finding (feel free to ignore):

1. ParallelBlockInputStream.java:89 — skip/handle ordering violates the "drop-in" contract. Read-ahead calls skipBlock() for later blocks before handleBlock() runs for earlier ones. The class javadoc promises "one at a time, in order"; a stateful adaptor that decides what to skip based on what it has seen so far will make those decisions on stale state.

2. ParallelBlockInputStream.java:95 — EOF handling only wraps readHead. A truncated block body throws out of process(), so adaptor.complete() never runs and up to pipelineDepth already-read blocks are silently dropped. BlockInputStream tolerated truncation and completed normally.

3. ParallelBlockInputStream.java:106 — in-flight futures aren't cancelled on the error path. With a caller-supplied executor, nothing happens at all; an owned executor gets shutdown() rather than shutdownNow(), so the queued decode backlog keeps expanding blobs (up to 32 MB each) whose results nobody will ever read.

4. ParallelBlockInputStreamTest.java:23 — the test doesn't exercise the interesting paths. numThreads=4 → pipelineDepth=8, but sample.pbf has only 4 blocks, so neither the backpressure delivery branch nor the skip branch is ever hit. A reordering bug in the real-world path would pass green.