boot: MIDIIn.connectAll stopped returning, and it took the whole rig's sound

A plain 'systemctl --user restart parvagues-sc' produced no sound at all for
thirteen minutes. sclang printed 'MIDI Destinations:' and then blocked
forever -- State S, 1s of CPU in 97s, wchan futex_wait_queue -- so it never
reached 'Booting server' and scsynth never existed. The watchdog then
restarted the unit into the same wall twice and tripped StartLimitBurst, so
the unit also refused to start until reset-failed.

Isolated with a three-line probe: MIDIClient.init returns, connectAll does
not, and connecting every source to inport 0 one at a time returns and
reaches ALL CONNECTED. Reproduced on a CLEAN MIDI world -- System, Midi
Through, LCXL3 1, PipeWire, nothing of ours -- so it is not contention, not a
stale client, not the port count, and not the driver.

connectAll pairs source i with inport i, so it wants as many SC input ports
as the box has MIDI sources and walks off the end. This rig has exactly one
input worth having, because every MIDIFunc below listens on inport 0. So ask
for that: same sources, one funnel, no index arithmetic. scsynth now boots in
6 seconds.

Found while restarting SC to pick up the 90s_synatm link and s.latency 0.1 --
which is precisely the restart TODO_GIG.md schedules for the START of the
rehearsal. The boot path had not been exercised since Sunday 17:57 and it was
broken; discovering that at 5pm Thursday instead of 00:55 Wednesday would
have cost the gig.

start_and_midi.scd

@@ -26,7 +26,24 @@ var osc;
 osc = NetAddr.new("127.0.0.1", 6010);
 
 MIDIClient.init;
-MIDIIn.connectAll;
+// NOT `MIDIIn.connectAll`. On 2026-09-24 it stopped returning: sclang printed
+// "MIDI Destinations:" and then blocked forever in futex_wait_queue, 1s of CPU
+// in 97s, so scsynth was never booted and the rig had no sound at all. The
+// watchdog then restarted the unit into the same wall twice and tripped
+// StartLimitBurst, which is why it also refused to start (reset-failed first).
+//
+// Isolated with a 3-line probe: `MIDIClient.init` returns, `connectAll` does
+// not, and connecting every source to inport 0 one at a time returns fine and
+// reaches "ALL CONNECTED". Reproduced on a CLEAN MIDI world — only System,
+// Midi Through, LCXL3 1, PipeWire — so it is not contention, a stale client or
+// a port count.
+//
+// The reason is what connectAll actually does: it pairs source *i* with inport
+// *i*, so it needs as many SC input ports as the box has MIDI sources, and it
+// walks off the end. This rig has exactly one input worth having — every
+// MIDIFunc below listens on inport 0 — so ask for that directly. Strictly more
+// conservative than connectAll: same sources, one funnel, no index arithmetic.
+MIDIClient.sources.do { |src| MIDIIn.connect(0, src) };
 
 // Initial: sends velocity on note's channel
 // Disabled in favor of launchpad control.