Consider streaming decryption/write path to reduce peak memory usage for large files

I noticed the current download verification/decryption flow buffers the full encrypted file into memory before decrypting.

Current flow appears to:

accumulate encrypted chunks in chunks[]
concatenate them via concatBytes(...chunks)
allocate another full plaintext buffer with new Uint8Array(pLen)

This can significantly increase peak memory usage for large files, especially on mobile browsers.

The crypto layer itself already seems stream-capable (sbInit, sbDecryptChunk, incremental Poly1305 state), so I was wondering whether a more streaming-oriented architecture could be considered in the future.

Possible direction:

download chunk
→ decrypt incrementally
→ write plaintext directly to OPFS/temp storage
→ finalize/verify auth tag at end

This could reduce peak RAM usage from approximately full-file-size multiples down to near chunk-size memory usage.

I understand there are important tradeoffs around:

final authentication validation
temporary storage cleanup on auth failure
padding/header parsing
resumable download behavior

So I wanted to ask whether this direction would be desirable before experimenting with an implementation.

Start by locating the download verification/decryption flow that accumulates chunks[], calls concatBytes(...chunks), and allocates Uint8Array(pLen), then read the streaming primitives sbInit and sbDecryptChunk. The issue does not define an implementation scope; clarify the architecture and acceptance criteria for incremental writes, final authentication failure cleanup, padding/header parsing, and resumable downloads before coding.