Gen 3 keyboards: stop sending the lighting opcode that silences their keys

[fbnlrz]

An Apex Pro Gen 3 (1038:1640, firmware 4.15.3) is the first wired Gen 3
board to be measured rather than inherited from OpenRGB and apex-tux, and
it refutes one of the entries it was given.

The bug

0x40 is not per-key lighting on that board. It suspends key reporting for
as long as frames keep arriving — which, with an animated effect at 30 Hz,
is permanently. The keyboard stops typing while Inari runs, and the reporter
described it as "it works briefly, then goes off, then on again, in an
endless loop".

Counting real input events off the board's own /dev/input nodes while
replaying Inari's writes in phases:

sent	keys/s
nothing	4.9
OLED 0x61 @ 2 Hz	4.4
direct 0x40 @ 5 Hz	0.2
direct 0x40 @ 30 Hz	0.1

It is the opcode, not the write load and not the payload: a bare 0x40
carrying an explicit zero key count and 641 zero bytes takes the board to
0.0 keys/s just as reliably, and it recovers within a tick of the frames
stopping.

The reason this shipped is worth recording. Every write is acknowledged at
a flat 1.2 ms throughout — no EPIPE, no timeout, nothing in the log. The
board answers endpoint 0 from an interrupt while whatever 0x40 starts
starves its matrix scan, so the failure is invisible to the writer and shows
up only as a dead keyboard. Two plausible theories were checked and
discarded on the way: the kernel log proves the device never re-enumerated,
and the flat write latency rules out overloading it.

The fix

Model::direct_dialect separates "has per-key LEDs" from "Inari knows the
opcode for them" — the same distinction switch_dialect already draws for
the firmware commands, and for the same reason. direct_packet() returns
None where the dialect is a guess, the draw loop hands those boards to
their onboard profile instead, and has_per_key hides every Inari-rendered
effect in the UI rather than offering controls that would paint nothing.

Set false for 0x1640 and 0x1642 only. The OLED and the
firmware-rendered effects (Reactive, Colour shift) were unaffected on the
measured board and are left working. 0x61 was tried as a replacement: it
is harmless to key reporting but paints the wrong thing, so the wired Gen 3
per-key dialect stays unknown rather than trading one guess for another.
The likely missing piece is the start_driver_mode (0x6C) that the vendor
specification wraps around software control on these boards; that was not
tried.

Three documentation pages promised per-key RGB for these boards and have
been corrected.

Verification

475 Rust tests, 168 frontend tests, clippy -D warnings and tsc clean.

The regression test asserts at the point where the packet would be born
rather than at the writer, and it was checked by reverting the fix and
watching it go red. The fix itself was verified against the hardware: with
the built binary and the exact configuration that caused the report, the
keyboard reports 1.4 keys/s where it previously reported 0.1, and the
installed binary is hash-identical to the one that was measured.