Bound chunkset uncompressed size before allocating

@puffyCid is already working on this.

Since Jul 26, 2026.

## Summary

`ChunksetChunk::parse_chunkset` reads the on-disk `chunkset_uncompress_size` (a `u32`) and passes it directly to `lz4_flex::decompress` as the output size:

https://github.com/mandiant/macos-UnifiedLogs/blob/4c4e136e0210ea66fdce1413e6cd9e5aeb3c8a3e/src/chunkset.rs#L43-L77

A small malformed `bv41` chunk can therefore declare a very large output (up to `u32::MAX`) and trigger the corresponding allocation before decompression rejects the data. In a WebAssembly consumer this can terminate the worker and abort the scan; native consumers can experience process memory exhaustion.

This is an availability issue in our downstream use, not a result-integrity issue. I observed it in crate version 0.6.0 and confirmed the same path on current `main` at `4c4e136e0210ea66fdce1413e6cd9e5aeb3c8a3e`. A downstream archive-size cap does not prevent the allocation because it occurs inside this parser after the trace file has already been accepted.

## Suggested hardening

- Reject declared output sizes above a caller- or library-configurable maximum before allocation.
- Where possible, also reject sizes inconsistent with the enclosing chunk/container bounds.
- Add a regression case using tiny compressed input with an oversized declared output.

A configurable limit would preserve support for legitimately large logs while giving constrained/WASM consumers a safe bound.