Add streaming download support

[BigLep]

The SDK currently supports streaming uploads but not streaming downloads. The download path accumulates the full response in memory (via the accumulating reader in synapse-core), which means pieces larger than available process memory can't be downloaded.

Background

There used to be a "Retriever" architecture that returned a `fetch` `Response` you could stream from, but that was removed and replaced with the current accumulating approach. This needs to be revisited.

Proposed API

The main complexity is CommP validation during download. Two approaches have been discussed:

1. Error on last chunk — the stream errors if CommP validation fails at the end (preferred)
2. Post-stream validation callback — a promise that resolves after stream completion to indicate whether CommP matched (used in FilBeam)

Consensus is that erroring on the last chunk is more idiomatic with WebAPI Streams, with the ability to opt out of validation for cases where it isn't needed.

Related

A merkle inclusion proof API or header for byte range piece retrievals from Curio is also a TODO (client and server) if we're going to encourage or demonstrating byte range retrievals.

[HavenCTO]

Thanks for pursuing this improvement, the accumulating download path is a real ceiling for anything layer-sized.

The specific use case I'm thinking about is agents creating new agents: modifying their own code, containerizing it, pushing the container to Filecoin, then booting it on EigenCloud. For that loop to work, you need normal docker pull / OCI registry semantics against decentralized storage, which means streaming multi-hundred-MB (or GB) layer blobs without buffering the whole thing. Bounded memory isn't optional here; it's table stakes.

There's prior work on OCI registries backed by IPFS that's directly relevant for benchmarking. fbongiovanni29/ipfs-oci-registry implemented this and published benchmarks and lessons learned about large-layer performance. The data in that repo could serve as a concrete reference workload for testing streaming download under realistic conditions — specifically, the layer sizes and access patterns that real container pulls produce.

Not trying to scope-creep this issue — just flagging that the streaming + CommP validation design here directly determines whether registry-style workloads are feasible on this stack.