fix: prioritize MIDI realtime output

[chmanie]

Summary

• isolate MIDI timing-clock ticks from app note/CC traffic
• deliver transport through a reliable queue ahead of clock ticks
• bound stale tick backlog while keeping clock generation non-blocking

Supersedes #599.

Verification

cargo fmt --all -- --check, firmware clippy, and ./build-uf2.sh pass.

Hardware test

• Generate heavy note/CC traffic while sending internal clock; confirm stable BPM externally
• Confirm Start, Stop, Continue, and Reset reach each configured MIDI output
• Confirm normal note/CC output under light load

[ArthurGibert]

Splits the shared MIDI output channel into three (notes/CC, clock, transport) so note/CC backlog can no longer starve clock ticks or Stop/Start. This is a genuine, well-targeted fix for real head-of-line blocking.

Hardware validation: flashed on real hardware and stress-tested well beyond this PR's original scope — 16 concurrent LFO apps (several in NRPN mode) continuously flooding the app-level MIDI queue (millions of intentional, by-design drops per send_cc's own drop-on-full-queue policy, confirmed not a bug). Across 1.2M+ log lines under this load, the clock priority channel recorded zero drops (verified via temporary instrumentation), the physical tempo LED stayed visually steady, and external MIDI monitoring confirmed clean clock signal on both USB and DIN outputs throughout. Confirms the PR's core mechanism works: clock delivery isn't starved by note/CC congestion, even at a load far beyond realistic use.

Residual gaps, suggest tracking as follow-up rather than blocking:

1. midi.rs:127 — MIDI_CLOCK_CHANNEL depth 16 lets stale ticks back up during a USB stall specifically, then burst-fire on recovery — contradicts its own doc comment. (Not exercised by this hardware test, which didn't stall the USB host.)
2. midi.rs:393 — sustained clock/transport traffic can starve MIDI_CHANNEL, backpressuring midi_distributor and potentially freezing an app task mid-send_note_on/send_cc.
3. midi.rs:360 — nothing flushes MIDI_CLOCK_CHANNEL on Stop/Start/Reset, so stale ticks can play out after Stop.
4. clock.rs:463 — the transport channel's blocking send reproduces the same stall-propagation bug this PR fixes, just relocated — a full transport channel now stalls CV clock output too.
5. Minor: midi.rs:357's manual try_receive pre-check is redundant with select4's own fixed poll order.
6. Minor, pre-existing: write_msg_to_uart0 has no timeout, unlike the USB path.

A related investigation (an unconfirmed user jitter report) additionally found that once the dispatcher commits to a write it isn't preemptible — up to ~28ms worst case for an NRPN write under a USB stall — and produced a fix for that plus #2 above, now on branch fix/midi-jitter-on-realtime-priority (pushed, not yet a PR).

Recommend merging as-is given the hardware validation above, and tracking the remaining gaps as documented follow-up.