Fix slcan DLC/payload and console CAN id token

[sccsltd]

Summary

• Lawicel slcan treated DLC 8 as 0 (DLC % 8), so python-can 8-byte frames left the wire as empty IDs (t0480 / t7200).
• Payload bytes were written at even data[] indices only; hex2byte already consumes two hex chars, so a 3-byte UDS frame became 02 8E 3E instead of 02 3E 00.
• Console id 0x720 read tokens[t+3] after t += 2, which set a garbage ExtId (bench: 1159253378 instead of 1824).

Measured on a HydraBus running 0.12 against MS-CAN (125 kbit/s). After the patch, slcan 8-byte frames and can / id 0x720 / write 0x02 0x3E 0x00 match the host.

Test plan

• t720803E00000000000 (or python-can 8-byte 0x720) appears on the bus as DLC 8, not DLC 0
• t7203023E00 payload on the wire is 02 3E 00, not 02 8E 3E
• HydraFW console: can then id 0x720 reports ID 1824 / 0x720
• Existing DLC 0–7 slcan frames still encode correctly
• Extended-ID T frames still parse (DLC nibble at index 9)

Made with Cursor

[bvernoux]

The commits carry a "Co-authored-by: Cursor cursoragent@cursor.com" trailer, so the change was produced by an AI coding agent.
I do not merge AI-generated code into this project, everything here has been hand-written for over ten years and that will not change.
If you want to implement the change yourself and explain the reasoning behind it, I am happy to review a new PR with no AI agent among the contributors.
Thanks for understanding.

[sccsltd]

Your loss, the code is clean, its been fully tested on the hardware, the bug was found by the ai when it was dignosing why your handwritten code wouldnt send ford can messages to an ipc. Merge or dont I dont care, my fw is patched and works, infact im not even running hydrafw on the board now so 🤷