Stream EdgeZero asset responses instead of buffering them

[aram356]

Summary

On the EdgeZero entry path, asset-route responses (including Fastly Image Optimizer output) were fully read into the Wasm heap before being sent, instead of being streamed to the client. This streams them, matching the legacy path.

handle_asset_proxy_request already requests a streaming origin response (with_stream_response) and returns a Body::Stream. The EdgeZero dispatcher was discarding that: dispatch_asset_fallback drained the stream via buffer_asset_body (a BoundedWriter capped by publisher.max_buffered_body_bytes) and re-attached the bytes as a buffered Body::Once, then edgezero_main sent it through the buffered-only compat::to_fastly_response(...).send_to_client(). This was a deliberate interim during the dual-path cutover.

The legacy main.rs path never buffered — its HandlerOutcome::AssetStreaming arm commits headers with stream_to_client() and pipes the body chunk-by-chunk via stream_asset_body. This PR wires the same seam into the EdgeZero path.

Changes

• dispatch_asset_fallback attaches the origin Body::Stream to the response instead of buffering. HEAD and bodiless statuses (204, 304) drop the stream so they keep the origin Content-Length and carry no body.
• edgezero_main now sends through a new send_core_response helper: Body::Stream responses are committed header-first via stream_to_client() and piped with stream_asset_body; buffered Body::Once responses are sent in one shot. Both send sites use it.
• Removed the now-dead buffer_asset_body / BoundedWriter usage and refreshed the stale buffering docs.

Publisher (HTML) responses remain buffered — unchanged.

Why no edgezero change

edgezero_core::body::Body already carries a Stream variant, and the buffering lived entirely in trusted-server-adapter-fastly. The dependency stays pinned to edgezero@branch=main; this is not part of edgezero PR #269 (the CLI-extensions epic), which is unrelated scope.

Test plan

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo test --workspace (adapter 107 passed incl. the new test; workspace 1420+ passed, 0 failed)
• cargo build --package trusted-server-adapter-fastly --release --target wasm32-wasip1
• New regression test dispatch_asset_fallback_streams_origin_body_without_buffering injects a streaming HTTP client and asserts the dispatched asset response body is Body::Stream.

Note: the end-to-end stream_to_client() send seam in send_core_response requires the Fastly Compute runtime and is covered the same way the legacy AssetStreaming path is — the chunk-piping primitive stream_asset_body has its own unit test in core (stream_asset_body_reports_mid_stream_origin_errors).

Closes #826.
Part of #480.

[ChristianPavilonis]

tested on staging, didn't get any 502 errors.

[prk-Jr]

Summary

Swaps the interim buffered-asset path for real streaming on the EdgeZero entry point, restoring parity with the legacy AssetStreaming behavior. dispatch_asset_fallback now attaches the origin stream instead of draining it into a bounded buffer, and the new send_core_response commits headers via stream_to_client then pipes the body chunk-by-chunk. Tightly scoped (3 files), well-documented, CI green. Approving.

Non-blocking

📝 note

• OOM cap removed for assets: the interim publisher.max_buffered_body_bytes guard no longer applies to asset bodies. Intentional and correct — streamed bodies never materialize in the Wasm heap — and it resolves the asset portion of the streaming cutover. Worth confirming the deferred "dedicated asset cap" decision stays tracked in #495 now that assets have no cap at all.

🌱 seedling

• Entry-point piping lacks a direct unit test: the new dispatch_asset_fallback test asserts the dispatch returns a Body::Stream, but the actual send_core_response streaming arm (stream_to_client → stream_asset_body → finish/drop) is only exercised by the EdgeZero integration test in CI. StreamingBody is awkward to unit-test, so deferring is reasonable — noting for future coverage.

⛏ nitpick

• Duplicated streaming-send sequence: the skeleton → stream_to_client → stream_asset_body → finish/drop sequence in send_core_response (main.rs) is duplicated by the legacy HandlerOutcome::AssetStreaming arm (main.rs:638). Since the legacy path is slated for removal at the streaming cutover, extracting a shared helper is probably not worth it — noting for awareness.

CI Status

• cargo fmt: PASS
• cargo test: PASS
• vitest: PASS
• integration tests (incl. EdgeZero entry point): PASS