The desktop icon brought Ardour up at 23:59 and the shell reported it Killed
ten seconds later, three lines before gig-up said 'gig-up done'. One root
cause under three complaints:

parvagues-protect's ardour:80 target promotes Ardour's GUI thread to
SCHED_FIFO/80. Its audio thread already gets RT from the backend the right
way (AudioEngine 1, FIFO|RESET_ON_FORK at 83, above the GUI), so the
promotion buys nothing and costs two things. RLIMIT_RTTIME is inherited and
differs by launcher -- gnome-shell hands children 200000us, a systemd user
unit hands them unlimited -- so an Ardour started from the icon carries a
200ms realtime budget, and loading the session blows it: SIGXCPU then
SIGKILL, with no kernel log line, which is why the journal looked clean.
And a GUI thread at 40-85% of a core on a realtime policy misses deadlines:
xrun_by.ardour went 0->46 in six minutes, and it is chronic, not new --
5172, 4852, 1114 and 987 ardour xruns in the Sep 10/18/20/22 sessions.

d1 alone on the speakers was never a second bug; it is what WirePlumber
does with SuperCollider:out_1/2 when there is no Ardour to route through.

Also: the DJF overlay's third row was an empty string, which is a row paying
no rent. It now carries travel from the bypass detent as a signed percent,
each side normalised against its own throw so 100% means end stop. The
cutoff stays on row 2 -- row 3 is the bezel row.

Findings in TODO_GIG.md with Thursday reordered; story in armada/tasks/046.