A failing setup stage reports its status and discards its reason #377

Question

A failing setup stage writes the sentence that says why to stderr — deliberately, so a developer can act on it (flows/provision.rs:1015-1022) — and nothing reads it. setup_pass captures both streams and reads only stdout for the probe report (flows/provision.rs:1944-1946); Answer::stderr() exists and five other devpod call sites read it. So StageFailed carries {workspace, stage, status, loudness} and renders as <ws>: the <stage> setup stage exited <status>. (dl/src/render.rs:2234-2240) — the status and no reason, every time.

This is what made #367 undiagnosable: the herdr stage refused for one readable reason (no python3 in the container), said so on stderr, and a launch printed only exited 1. That stage is gone in 0.12.0, but the hole is not herdr's — hostname, zellij and title all fail the same silent way. Carry the reason on StageFailed and render it.

Settle inside this ticket: attribution, which is the whole difficulty. One bash -lc runs every stage into one stderr stream, so a line is not labelled with the stage that wrote it — either the pass marks stage boundaries on stderr the way PROBE_MARK marks the report on stdout, or the event carries the pass's whole stderr once rather than per stage. Also whether the reason obeys FailureLevel (the hostname stage is quieter() because sudo hostname fails on most cold launches — its reason is noise, not news), and how much of a chatty stage's stderr is worth keeping: the zellij stage redirects a whole pixi install there, which is pages.