fix(runtime): stop WASM pipe reads from stalling for maxBlockingReadMs (#1959)

[abcxff]

A WASM pipeline stage read from a pipe via a synchronous, blocking process.fd_read on the sidecar reactor thread. While parked in that kernel read, the reactor could not run the upstream stage to completion, so the writer never closed its pipe end; the reader only unblocked when the maxBlockingReadMs watchdog fired — once per stage. A low cap turned that into a guest-visible Would block/EAGAIN with a nonzero exit; a high cap into a multi-second-per-stage stall (e.g. env | sort | sed ~20-30s).

Make WASM process.fd_read non-blocking (Some(Duration::ZERO)), mirroring the sibling process.fd_write path: the runner poll+retries a logically-blocking fd on EAGAIN, the reactor stays free to run the writer, and the reader observes EOF promptly. Pipeline latency no longer depends on maxBlockingReadMs.

Add a regression test asserting a low-cap pipeline succeeds without watchdog EAGAIN (with exact-output checks) and that three-stage pipeline latency is independent of the cap.

[abcxff]

Stack for rivet-dev/agentos

• #1965 fix(runtime): stop WASM pipe reads from stalling for maxBloc … 👈
• main

Get stack: forklift get 1965
Push local edits: forklift submit
Merge when ready: forklift merge 1965

_{change knuwtupr}

[railway-app]

🚅 Environment agentos-pr-1965 in rivet-frontend has no services deployed.

[abcxff]

Fixes #1959