dbserver: fix CDJ-saved cue colour showing orange instead of green

[vynulldev]

What & why

Setting a hot cue on the CDJ and then viewing it in the web UI showed the wrong colour — Pioneer orange instead of the deck's green.

Root cause, from an actual saved blob: the CDJ encodes a cue's colour in the RGB bytes (0x4f-0x51) of the 124-byte NXS2 blob, with a zero palette index at 0x4e. A default hot cue arrives as index 0 + RGB 00ff30 (green). ParseCueBlob read only the index (0), stored color_id 0, and the web UI painted palette 0x00 (orange). The deck itself was always fine — we re-serve the raw blob verbatim, RGB intact — so this was a stored/displayed-colour bug only.

The fix:

• Extract the colour extraction into cueColorFromBlob. When the palette index is 0, recover the colour from the RGB bytes by reverse-mapping to the nearest palette id (00ff30 maps to 0x16, the same green the web-UI and import cues use). A non-zero index stays authoritative; all-zero RGB stays uncoloured.
• loadAll now re-derives the colour of every CDJ-saved cue from its raw blob on startup, so cues saved before this fix (whose JSON kept color_id 0) auto-correct on the next launch. Web-UI/synthesized cues have no raw blob, so they keep their stored colour.

No change to what's served to the deck (the raw blob is re-served verbatim); this only corrects the colour we store and display.

Hardware testing

• Tested on: N/A: this doesn't change deck behaviour — the served cue blob is unchanged. It corrects the colour Vynull stores/shows for cues the deck saved. Verify in the web UI: set a hot cue on the CDJ, and its swatch shows green rather than orange.

Checklist

• go build ./..., go vet ./..., and go test ./... pass
• gofmt -l . is clean
• New source files carry an SPDX header (GPL-3.0-or-later)
• Tested on real hardware (deck + firmware noted above), or this change doesn't affect deck behaviour
• I agree my contribution is licensed under the project's GPLv3