Correcting my own reading from forty minutes ago, because the fix differs.
The first call was that find_seq_port had bound the driver's FB port, since it
matches port names by substring and 'ParVagues LCXL3 FB' contains 'ParVagues
LCXL3'. Then measured it: aseqdump -l lists SOURCES only, the FB port is an
input, and it does not appear in that listing at all. The resolver could never
have picked it. 131:0 was the right port -- at 10:38:12, fourteen hours ago.

The fault is one word in the docstring. 're-resolved every connect' only fires
when the aseqdump connection drops, and it never dropped. The driver's ALSA
client id moves on every republish -- 131 to 130 to 133 tonight alone -- and
when the client underneath disappears aseqdump keeps running, subscribed to an
address that no longer exists. No drop, no reconnect, and 16227 sample rows
with zero cc rows. A dead seq subscription looks exactly like a quiet surface,
which is why ten sessions passed without anyone noticing.

The matcher hardening here (exact name beats substring, FB excluded like HUI)
is kept because it is more precise, but it is NOT the fix and the comment says
so. The real fix is liveness -- rebind when the bound address leaves
aseqdump -l -- and that is post-gig. Tonight's session is rebound to 133:0.