PLN's report: "no impact of lcxl in ardour... why would i need to remap midi
controls there across lcxl gens?" He is right: he never needs to remap. The
session file has the learned bindings (v2 CC 77-84 + 13-16, channel 1) and the
lcxl3-driver emits exactly that. The path was broken in TWO places, both by
name-vs-identity rot:

1. midi-autoconnect resolved its source by NAME and connected "name:0" — but
   aconnect resolves CLIENT names only, and the driver's virtual port carries
   its name on the PORT line (client = python-rtmidi's 'RtMidiOut Client').
   The connect failed into 2>/dev/null for exactly the source the candidate
   list most prefers, so Midi Through carried NOTHING in DAW mode. Now the
   resolver returns a numeric client:port address (awk over aconnect -i,
   matching client AND port lines). Fourth name-identity bug of the day.

2. Ardour's Generic-MIDI input connection was saved by device identity, and
   that identity was "ALSA;;C922 Pro Stream Webcam" — the webcam had taken
   over the slot the surface once owned. The purest stale-binding specimen the
   rig has produced. tidal-ardour-autoroute now asserts
   Midi-Bridge Midi Through -> ardour:MIDI Control In on its 2 s cadence,
   no-op until Ardour registers the port, permanent once it does.

Midi Through stays the rendezvous ON PURPOSE: v2 raw or v3-translated, both
feed it, which is what keeps the classic LCXL plug-and-play (the BC
constraint). Ardour 9.7 note for the archives: the Control Surfaces page is
now a vendor tree built from the .map files' manufacturer field — the old
"Generic MIDI" lives under vendor "Any" (GenericMIDI.map, manufacturer="Any"),
NOT under "Other", and Novation's "Launch Control XL (generic)" entry is the
factory map that would OVERRIDE the learned bindings — do not enable it.