In pipe mode, ReceiveFrontendSyncMessage was writing sync frames
directly to client.stream inside the select! command handler. If the
daemon was sending data at the same time, the select! would drop the
pending socket read future, then the command handler would write to the
stream, corrupting the framing. The daemon would then read payload bytes
as a length prefix, producing bogus frame sizes (observed: 1.15 GB).

Fix: buffer outgoing pipe frames in a VecDeque and flush them at the top
of the loop BEFORE entering select!. This ensures writes only happen when
no read is pending on the socket. The queue is drained synchronously
before the next select! iteration.

Full peer mode (runtimed-py) is unaffected — its writes go through
sync_to_daemon() which owns the read/write sequence.

In pipe mode (#608), the Automerge sync path doesn't deliver output
changes — the daemon's sync state tracks the relay peer, not the WASM
peer, so all sync frames arrive with changed=false. materializeCells
never runs after execution, and outputs never render.

Re-enable the broadcast-driven output path (appendOutput via onOutput
callback). The broadcast pipeline works correctly — outputs arrive,
blob manifests resolve, and the external store updates.

No duplicate risk: since sync frames have changed=false,
materializeCells doesn't run after execution, so there's only one
source of output updates (broadcasts).

The proper fix is to align the sync states so the daemon talks
directly to the WASM through the pipe (skip do_initial_sync in
pipe mode). Tracked as a follow-up.