fix(radio): lua telemetry handling

[3djc]

Reports of radios rebooting into EMERGENCY MODE while using the Rotorflight Lua scripts, and attemps to address it, at least partially.

1. The Lua telemetry queues have no locking

Telemetry RX runs in the FreeRTOS timer task (prio 2, via xTimerPendFunctionCallFromISR); Lua runs in the menus task (prio 1). So RX preempts Lua at any instruction, and:

• telemetryQueues is mutated from the menus task while pushTelemetryDataToQueues() iterates it from the timer task, unlocked.
• ~LuaScriptManager unregisters its queue and then frees it as two separate steps — the producer can still hold that pointer.

Colorlcd only. It fires on script/widget open and close with telemetry streaming.

Fixed with a mutex over the list, held across the whole push loop, and unregister+free collapsed into a single destroyTelemetryQueue() under that lock.

2. crossfireTelemetryPush() bounds-checks the wrong value

lua_gettop(L) > TELEMETRY_OUTPUT_BUFFER_SIZE compares the argument count (always 2), not the payload length, leaving the payload unbounded. pushByte() drops silently past 64 bytes, but the frame's length byte and crc8(data + 2, ...) still use the full length and read past the buffer. Now checks the real frame size, keeping the length as lua_Integer until validated so a >255 table can't wrap through uint8_t.

The payload loop also lua_rawgeti'd each element without popping it, growing the Lua stack one slot per byte — past LUA_MINSTACK that writes beyond the reserved C-call slots. Added the missing lua_pop().

Untested (as in I wasn't able to reproduce the EM without that fix, so could not confirm this fixes it)

[philmoz]

Are the same fixes needed for ghostTelemetryPush?

[3djc]

Are the same fixes needed for ghostTelemetryPush?

Technicaly no, because Ghost caps payload at 10 bytes, so bellow LUA_MINSTACK (set at 20)

But yes, it would look nicer and more consistent to have it there too, incoming