feat: optional size limits on streaming CAR decode and encode

[tabcat]

Problem

Decoding a CAR from a streaming source (*.fromIterable) reads a varint length, then buffers that many bytes into one contiguous allocation via reader.exactly(length) before yielding anything. This happens for the header, each CID, and each block body, and none of those lengths is bounded, so a malicious CAR can declare a huge length and force a near-arbitrary allocation. The caller cannot prevent it: a block is only visible once fully materialized, so a downstream size check runs too late. (The in-memory fromBytes path is unaffected; it slices an already-bounded buffer.)

The encode side is a conformance concern rather than allocation safety: a caller who decodes untrusted CARs under a chosen set of caps could still write a CAR that violates that same profile, and so emit output it would refuse to read back. Applying the same caps on the streaming writer gives one size profile enforced on both ends.

Change

Adds a shared, off-by-default CarCodecOptions to the four streaming decoders and the two streaming writer entry points:

// decode
CarReader.fromIterable(stream, { maxHeaderLength, maxCidLength, maxBlockLength })
CarBlockIterator.fromIterable(stream, options)
CarCIDIterator.fromIterable(stream, options)
CarIndexer.fromIterable(stream, options)

// encode
CarWriter.create(roots, options)
CarWriter.createAppender(options)

The three caps, all in bytes:

• maxHeaderLength: the CAR header (the dag-cbor header block; on decode also covers the v2 pragma and the inner v1 header)
• maxCidLength: each CIDv1 CID, measured as the full CID (version + codec + multihash). CIDv0's bare multihash is not checked.
• maxBlockLength: each block body

A length strictly greater than a cap throws a RangeError (matching the capacity-violation precedent in CarBufferWriter): on decode before the bytes are buffered, on encode before they are written. All three default to undefined, so existing callers, the fromBytes paths, and CarBufferWriter are unaffected. Setting the same CarCodecOptions on both ends gives one size profile that holds on read and write.

Closes #185