feat(surface): the LCXL3 bench — a place to look at the new device before trusting it

Not an extension of lcxl-leds.py, deliberately. v2 and v3 are different
protocols, not different constants: v2 is a template/palette SysEx driving
3-colour buttons, v3 has true RGB per control, a 128x64 OLED, endless encoders,
and a CC map that only exists in DAW mode. Folding v3 in would produce a file
that lies about both. When the numbering settles, lcxl_grid.py stays the one
authored table and this becomes its transport.

Every byte sequence in here is quoted from the official programmer's reference
v1.0, not recalled — RGB is 01h 53h <idx> <R> <G> <B>, the bitmap is 09h with
1216 bytes and a 7Fh terminator rather than F7h, and the feature CCs live on
channel 7 of the DAW in port.

Transport is python-rtmidi via mido rather than shelling out. aseqsend on this
system takes -s as a FILENAME: `aseqsend -p 20:0 -s "B0 25 05"` prints
'cannot open B0 25 05' and exits 0. A silent no-op, which is how a first paint
attempt can look like a hardware answer. lcxl-leds.py shells out that way
today, which is worth revisiting.

The subcommand that matters is `keystone`. The guide files 'Colouring the
surface' and 'Controlling the screen' inside the DAW mode chapter, prefaced
'only available once DAW mode is enabled'. If that is how the document is
organised rather than a hardware restriction, paint works in standalone and the
corpus keeps its v2 numbering — a 169-file difference. So it gets tested in
three steps with PLN's eyes on the surface, not assumed either way.

`sweep` exists for the same reason: the DAW-mode index map is a low-resolution
diagram in the PDF, so we light each index in turn and read the map off the
hardware.