ac generate: process exit code doesn't reflect a mid-run daemon error

[mkovero]

Context

Found while fixing PR #441's Codex QA finding on scripts/rig/probe-outputs.sh (the emission loop that drives one output at a time and checks exit status of every step before letting anything emit).

ac generate ... (ac-rs/crates/ac-cli/src/commands/generate.rs, wait_for_stop/wait_loop) blocks until the daemon sends a done topic, an error topic, or the operator hits q/Ctrl-C. On the error path, wait_loop returns Err(reason), and wait_for_stop just prints it:

if let Err(reason) = result {
    println!("\n  {reason}");
}

main() doesn't inspect that return value or call std::process::exit(1) for it, so the process exits 0 regardless — a mid-generation daemon-side failure (audio backend drops out, routing rejected after the command was accepted, etc.) is only visible as printed text, not as an exit code.

This is distinct from the ack-rejection path: a command the daemon rejects outright goes through check_ack, which does call std::process::exit(1) before wait_for_stop is even reached. That path already fails closed. It's specifically an error arriving after generation has started that gets swallowed.

Why it matters

Rig scripts (probe-outputs.sh, and by the same shape acoustic-ir.sh's ir_probe invocation, though that's a separate binary) rely on ac's exit code to decide whether an emission was clean. A script that does ac generate ... ; wait "$genpid" currently cannot distinguish "generated cleanly for the full duration" from "started, then the daemon errored out partway" — both exit 0. In practice a failure here likely means a near-silent capture (visibly low level to a human reading the wiring table), but nothing script-side flags it.

Suggested fix

wait_for_stop/wait_loop's Err path should propagate to a nonzero process exit — either have run_sine/run_pink call std::process::exit(1) on Err, or have main() do it based on a return value threaded up from commands::dispatch. Likely affects monitor/other commands using the same wait_loop/wait_for_stop pattern; worth checking monitor.rs, monitor_tui.rs too.

Filed as a follow-up, not fixed in #441 — out of that PR's scope (rig scripts/docs, not ac-cli exit-code behavior).