capture pays DRAIN_GRACE once per pipe, so the drain bound is 1.0s not 0.5s

[blooop]

Residue from verifying #355 (found 2026-08-29, on main).

capture drains stdout then stderr serially (rust/devlaunch-runner/src/lib.rs:497-498, collect(stdout) then collect(stderr)), and each collect gets its own DRAIN_GRACE. Two held pipes therefore cost up to 1.0s, where a reader of the timeout design could take the grace as a single bound on the drain.

The DRAIN_GRACE doc comment is accurate as written: it says how long collect gives a drained pipe to reach EOF, which is per-pipe and true. So this is a behaviour question, not a wrong comment: should the two drains share one deadline?

Context: the drain bounds landed in PR #343 (#301/#302); the EINTR half of the review residue was #355, closed as already fixed by #343.

[blooop]

Resolved: share one deadline across both drains. Compute deadline = Instant::now() + DRAIN_GRACE once in capture and pass it to both collect calls, so DRAIN_GRACE bounds the drain rather than each pipe; update the DRAIN_GRACE doc comment to say so. Verified on main: devlaunch-runner/src/lib.rs:497-498 drains serially and the 500ms grace at :1026 is per-collect.

Why now rather than fog: the comment at lib.rs:489-491 names git's ssh ControlMaster as the production case for a held pipe, and #422 (now in build) adds a second ControlMaster on the hottest path, so the multi-pipe case is about to become the common case. Decided against per-pipe on latency, not correctness: a timed-out outcome already drops its output, so nothing is lost. Lands in #422's PR as its own commit.

[blooop]

Built: #523, as its own commit (fix: DRAIN_GRACE bounds the drain, not each pipe) beside #422's, exactly as the resolution said.

capture takes deadline = Instant::now() + DRAIN_GRACE once and hands it to both collect calls; collect now takes the deadline rather than computing one. The doc comment at the constant says it bounds the whole drain and why the second pipe loses nothing by sharing it: both drain threads start before the wait for the child does.

Measured rather than argued. two_pipes_one_descendant_holds_cost_one_grace_between_them spawns a real setsid'd descendant holding both pipes; against the per-pipe grace it fails at 1.008s, and passes at ~0.5s with the shared deadline. It asserts a floor as well as a ceiling (over four fifths of one grace), so an EOF that did arrive cannot let it pass having pinned nothing.

Not merged.

[blooop]

Green at 8739e57 (commit 8739e57, fix: DRAIN_GRACE bounds the drain, not each pipe). Rebased on current main, every check passing including gate. Left open, not merged.