Fix MIDI running status + sequencer freeze under external MIDI clock (F8)

[bwhitman]

Fixes #747. Addresses real-world reports of an AMYboard "crashing" / no longer receiving MIDI when an external device streams MIDI clock (F8).

Three related F8 / MIDI-clock bugs, in two configs:

1. Running status broken by interleaved real-time bytes (default config)

System Real-Time messages (0xF8–0xFF: clock, start, stop, active sensing) may be interleaved anywhere in the stream — even between the data bytes of another message — and must not disturb running status. convert_midi_bytes_to_messages overwrote current_midi_message[0] for every status byte, so a clock byte (24 ppqn while a sequencer plays) clobbered the stored note-on status. The next running-status note's data bytes then resolved to status 0xF0, matched no case, and were silently dropped:

90 3C 40     note-on, dispatched fine — running status now 0x90
F8           clock → current_midi_message[0] becomes 0xF8   ← clobbered
3E           status = 0xF8 & 0xF0 = 0xF0, matches no case → byte DROPPED
40           same → DROPPED

This is the "stops receiving MIDI" symptom in default config (sync off, F8 is otherwise a no-op). Fix: real-time bytes (>= 0xF8) dispatch via a scratch buffer and never touch current_midi_message[] / midi_message_slot; a genuine new status byte also resets midi_message_slot so a truncated message self-heals.

2. Sequencer freeze under external clock (sync enabled)

sequencer_external_clock was a one-way latch: sequencer_midi_clock_tick() set it true on the first F8 and nothing ever cleared it, so once the external clock stopped, sequencer_check_and_fill() early-returned forever and the internal sequencer froze until reboot — turning sync back off did not recover it. Fix: sequencer_external_clock_disable() (clears the latch, resumes internal clocking, re-anchors the tick timer), called from amy_external_midi_sync(0), making "sync off" a real recovery path. The internal-until-first-external-tick handover is preserved.

3. Transport (FA/FC) ungated

MIDI Start/Stop drove the sequencer unconditionally, so a connected DAW's transport could halt the AMYboard's own internal sequence even with sync off. Both are now gated behind external_midi_sync_enabled.

Testing

• make amy-module clean (-Wall -Wextra, no warnings); full suite 95 tests pass.
• Added a regression test TestMidiRunningStatusClock that feeds a raw byte stream through the parser — three running-status note-ons with an interleaved 0xF8 clock and 0xFE active-sensing — and asserts all three notes sound. Verified non-vacuous: it fails against the pre-fix parser (err=-30.1 dB, two notes dropped) and is bit-exact with the fix (err=-100.0 dB).
• This closes the underlying gap — the byte-stream parser previously had no coverage (inject_midi bypasses it). New amy.inject_midi_bytes() binding routes bytes through convert_midi_bytes_to_messages.

🤖 Generated with Claude Code

[bwhitman]

🎛️ AMYboard HW CI

Dispatched this PR's amy SHA to the tulipcc bench — it builds the AMYboard firmware with your change and runs it on the physical board (audio spectral-compared to a committed reference). Results post here in a few minutes.

[bwhitman]

🎛️ HW CI (physical bench)

Built from this AMY PR, pinned into the tulipcc amy submodule.

AMYboard (USB-MIDI + AMY zP → audio): ✅ PASS — flashed this PR’s firmware; all checks matched the references.

Tulip (TULIP4_R11; serial-REPL audio + WiFi screenshot): ✅ PASS — flashed this PR’s firmware; all checks matched the references.

⬇️ Artifacts: recordings · screenshot · serial logs · run logs

_{Self-hosted bench. Audio spectral-compared to ref/hwci_basic.wav + ref/tulip_basic.wav; Tulip screenshot pixel-compared to ref/tulip_screenshot.png. Both analog outs share one capture card, so the tests run sequentially.}