Stream sandbox file downloads end to end

[lamenting-hawthorn]

Problem

Sandbox file downloads currently buffer the complete file in each provider and then copy that buffer again into the HTTP response. The route contains a TODO to stream the response, but the current SandboxProvider.downloadFile contract and all implementations return Promise<Buffer>.

A route-only ReadableStream wrapper would not reduce peak memory because the provider has already materialized the complete file.

Proposed direction

Introduce a genuinely incremental provider contract, then stream it through the turns download route while preserving the current ownership/path checks, maximum file-size enforcement, response headers, and error mapping.

Likely surfaces:

• SandboxProvider file-download contract
• Daytona provider
• TFY sandbox transport
• local sandbox provider
• turns download route
• provider contract and route tests

Design questions

• Should the provider return a Web ReadableStream<Uint8Array>, an async iterable, or a response object containing stream plus known size?
• Does the Daytona SDK expose a streaming file API, or is a lower-level transport required?
• What chunked endpoint/protocol should the TFY sandbox use instead of base64 embedded in an exec result?
• Is a temporary buffered compatibility fallback acceptable, or should the contract change only when every provider streams genuinely?

Acceptance criteria

• Download bytes begin reaching the client before the complete file is loaded.
• Peak application memory is bounded by chunk/backpressure behavior rather than file size.
• Existing maximum-size and tenant/path controls remain enforced.
• Client cancellation stops provider reads.
• Provider contract tests verify progressive delivery and error behavior.