Stream stderr live for long-running commands instead of buffer-and-replay

> 🤖 Generated by the Daily AI Engineer

## Evidence & problem
`errorhandler.Executor.Execute` captures the whole run’s stderr into an in-memory buffer so a **failing** command’s stderr can be normalized into one clean `CommandError`. As of #6216 that buffer is flushed to the real stderr for non-failing runs — but only **after** `cmd.Execute()` returns.

For **long-running** commands this means live notices appear too late to be useful:
- `workload intercept` writes `intercepting inbound traffic … press Ctrl-C to stop` (`pkg/.../workload/intercept.go`) then blocks — the instruction only replays *after* interception has already ended.
- `open web` replays its browser-launch fallback only after the web server stops.

(Flagged by a Codex P2 review on #6216. This is pre-existing behaviour — before #6216 these notices were captured **and discarded**, so #6216 is strictly an improvement; the ideal is live streaming.)

## Why it is not a one-line change
Naively teeing stderr live *and* into the capture buffer would double-print on **failures** (the raw stderr live **plus** the normalized `CommandError` main.go prints) — which defeats the capture’s whole purpose (turn a failing command’s messy stderr into one clean message). A correct fix needs a way to distinguish *warnings/notices* (stream live) from *error output* (capture + normalize), which stderr does not carry today.

## Candidate directions (to evaluate)
- A tee writer that streams live, with the failure path reconstructing the normalized message **without** re-printing already-streamed content.
- A dedicated warning/notice sink (e.g. a `notify`-level writer) that bypasses the capture entirely, leaving only genuine error output buffered for normalization.
- Opting specific long-running commands out of capture.

## Acceptance criteria
- [ ] A long-running command’s startup notice reaches the real stderr **while the command is still running**, not after it returns.
- [ ] A failing command still prints exactly one normalized error (no double / raw + normalized output).
- [ ] Non-failing runs still surface their warnings (the #6216 behaviour is preserved).
- [ ] Regression tests cover live-notice delivery and the no-double-print failure case.

Size: M. Impact: correct, timely UX for long-running commands (`workload intercept`, `open web`, …).

Start in errorhandler.Executor.Execute and trace how stderr is captured, flushed, and normalized; then inspect the long-running paths mentioned in pkg/.../workload/intercept.go and open web. Add regression coverage for live notice delivery and failure output, with done defined by timely notices, one normalized failure message, and preserved non-failing warnings.

Written by the indexing model from the issue text.