feat(lighting): enable Lightpad rendering and LUMI key colors

[hyperb1iss]

Lightpad frames could be accepted without producing the requested colors, and LUMI had no per-key lighting API. This change restores device-side rendering for Lightpad grids and adds individual colors for all 24 LUMI keys.

The assembler relocates jump targets to their position in the complete program. Both renderers disable the firmware status overlay. The daemon uploads code separately from pixels, waits for the complete upload acknowledgement, then challenges the running renderer with a fresh nonce. Heap-state loss restarts that handshake, including when identical program bytes survive without another initialise callback.

LUMI exposes JSON key_frame (72 RGB888 bytes), discovery key_count = 24, and blocksd led keys [rainbow|HEX]. Firmware 1.3.0 or newer is required. The renderer enables default musical key handling while replacing key lighting. Factory programs remain active until a lighting request arrives; the existing Lightpad binary API stays compatible.

🛠️ Complete animation frames

Continuous input previously replaced unfinished heap targets, repeatedly updating the prefix while starving lower Lightpad rows. Each multipart transfer now finishes an immutable snapshot while newer desired frames coalesce separately. The encoder also reserves capacity for skip commands and its end marker.

Lightpad uses two 450-byte pixel banks. The host uploads into the inactive bank, then requests presentation after its heap packets are acknowledged. The renderer latches one bank for the entire repaint and acknowledges only after all 225 pixel writes. Session, sequence, and bank checks prevent stale replies from releasing a bank; retries and identical-code reconnects preserve ownership. Startup and recovery may blank the display during resynchronisation.

MIDI reception is independent of the 200 ms lifecycle timer. Incoming acknowledgements are processed immediately, while absolute timer deadlines and cooperative yielding preserve keepalives and other tasks during continuous traffic.

🧪 Validation

• Full just check passes on the final head: 625 Python tests, Ruff, ty, dashboard checks, docs build, packaging, and fresh installed-wheel validation.
• Independent decoded-wire tests verify complete snapshots, final convergence, resets, and cumulative acknowledgements, including 2,194 randomized packets.
• An independently rebuilt vendor VM passes 92 repaints / 20,700 pixel writes, including partial inactive-bank uploads, stale messages, retries, identical-code recovery, and presentation requests injected halfway through repaint.
• Independent native-thread callbacks through the real MIDI connection abstraction arrive between lifecycle ticks in under 2 ms. The original loop reproduced a 180 ms queue delay.
• On LUMI 1.3.9 over USB and Lightpad M 1.1.0 over DNA, a 15-second native Hypercolor sweep accepted 376 frames per device. Lightpad acknowledged 113 complete repaints, approximately 7.53 repaints/sec between the first and last acknowledgement, up from 1.46/sec before the receive-loop fix. These are logical repaint measurements, not physical LED scan timing.

The hardware owner confirmed whole-pad animation after the snapshot fix. Final visual feedback on buffered alignment remains pending. Physical MIDI/MPE preservation, cable/power-loss recovery, and hardware operation on macOS remain unverified. The vendor VM verifies the musical-handler arguments; a live MIDI/MPE exercise is still needed.

The matching Rust bridge is in Hypercolor #263. Python retains ownership of MIDI and the device protocol; Hypercolor supplies effects and spatial mapping.

The LUMI renderer now claims hardware brightness at 100% during initialization and validated readiness challenges, including reconnects with unchanged code. Host RGB/API brightness still controls dimming, and gamma is unchanged. Hardware readback confirmed brightness 100 in its 0–100 range. Config requests also include the SDK-required 32-bit reserved address field; three upstream C++ wire vectors cover the correction. Independent native-VM checks verified brightness calls, readiness ordering, unchanged musical-handler arguments, and black/white/patterned key frames.