The tool invented signal, and the invented signal sent an entire investigation
down the wrong road.

A run on 2026-07-28 came back with five different orbits at an IDENTICAL +0.0
dBFS peak. Twelve independent orbits do not peak at exactly full scale together
— that was one shared source (the mix) being measured five times, because the
capture nodes had acquired PipeWire links nobody asked for. `--target 0` is
supposed to stop pw-record auto-connecting to the default source, and usually
does, but not reliably.

The consequence was worse than a missing number. The contaminated table said
d4 and d5 had "recovered after seeding", so that got reported as a result, while
Ardour's own meters showed no input on those tracks at all. PLN was looking at
the truth and being told otherwise. A measurement tool that fabricates signal is
not a tool — it is a confident liar, and it outranks the human's ears in an
argument it should always lose.

Two changes:

  * link() now CUTS every pre-existing link into the capture node before making
    its own, so an auto-connection cannot ride along.
  * verify() re-reads the graph AFTER the capture window and asserts the node was
    fed by exactly the two ports we intended. Checked after, not before, because
    an auto-connection can appear at any point while the node is alive — a setup
    -time check would still let contamination through.

Rows that fail verification print "UNRELIABLE — ignore this row" INSTEAD of a
diagnosis, plus a summary naming what each bad tap was really linked to. Refusing
to answer is the correct behaviour here; a plausible wrong number costs hours.

Validated by re-running against the live rig: the clean table (d1/d2/d3/d7 with
signal, d4/d5/d9-d12 silent at source) matched what PLN could hear, where the
contaminated one had contradicted him. Confirmed on the way that the SC->Ardour
link mapping is exact (out_(2N-1)/out_(2N) -> ardour:Tidal NN for all 12), so the
disagreement was never routing.