The driver's own startup line said the gap out loud: "row A stays absolute:
A1-A4 are Ardour's, we hold no truth for them". So those four rings sat at a
flat rest colour while every other cell painted its value.

Two sources close it, and they are complementary rather than redundant:

1. A forwarded CC is an observation. When PLN moves A1-A4 the driver TRANSLATES
   that value on its way to Ardour, so at that instant it knows what the fader
   holds. It always recorded it in self.values; only ring_colour's
   Ardour-owned branch threw it away. Now it also marks the cc observed, and
   the ring breathes by audibility from the first touch.

2. Ardour echoes what it did NOT get from us. `<Protocol name="Generic MIDI"
   feedback="1" motorized="1" active="1">` was already on, and Ardour will not
   echo a change back to the surface that caused it — so source 1 covers the
   hand on the knob and source 2 covers the GUI, the mouse, automation and a
   session load, which is exactly where source 1 goes stale.

The feedback leg needed its own port. The driver already sends into Midi
Through (14:0) and Ardour's Generic MIDI reads from there, so listening on that
loopback would have fed the driver its own CCs back: no loop is possible now
because the send path and the echo path share nothing. And it is the one
binding here that lives in JACK rather than ALSA, because Ardour's control port
is a JACK port and only PipeWire's bridge makes ours visible there — so the
bridged name, which carries a playback index nobody should guess, is DISCOVERED
by suffix on every pass and re-asserted like every other binding on this rig.

Verified on the live rig, Ardour closed then reopened: the port publishes
(client 132 'ParVagues LCXL3 FB'), the bridge exposes it, the reconciler finds
and links it unaided, and it re-links within 5 s of a driver restart. Absent
Ardour it stays silent and returns False, costing nothing but the rest colour.