Two bugs I introduced or left standing in the two commits before this one.

SELECT PLUS READLINE DRAINS ONE LINE PER EVENT. readline() on a
TextIOWrapper pulls a whole chunk off the fd and hands back one line; the
rest sits in the wrapper's decoded buffer, where select() on the fd cannot
see it. A fader sweep is 100+ lines a second arriving in bursts, so the
tail of a gesture would be logged only when the NEXT gesture arrived,
stamped with the wrong second. Measured on a real pipe: 1 of 50 lines,
against 50 of 50 once the reader owns its own byte buffer. The old
blocking iterator never had this; select made it possible and nothing
tested it, because the fake pipe never wrote anything.

Same file: a rebind left the old aseqdump running. Harmless while rebinds
only happened after the stream ended -- and the previous commit made them
ordinary, since the driver restarted six times that night. The
steady-state check now also reuses one 'aseqdump -l' for both questions.

RUNNING IS NOT LISTENING. gig_record resolves its sink once, at start, and
gig-up starts units BEFORE it opens Ardour -- so in the flow that is
actually pressed it resolves while Ardour is closed, falls back to the
default sink, and if the laptop speakers are then cut (correct on stage)
the black box records a sink nothing reaches. 'gig_record.sh check' asks
whether what it HEARS is still where Master GOES, read off the running
process rather than recomputed; a new ADVISE probe runs it and skips when
Ardour is closed. "Not running" stays the other probe's question.

The master_sink awk now has tests, including the state the gig was in with
Master linked to two sinks at once -- it takes the first, which is a real
choice and not a good one, so the script names the sink it picked and the
test makes the ambiguity visible instead of silent.