fix: validate optData length in FCP_Get_OptData to prevent buffer overflow

[steps-re]

Summary

FCP_Get_OptData() can overflow the caller's optData buffer when parsing a malformed frame.

Details

The function reads the optional-data length byte from a received frame and memcpys that many bytes into the caller's buffer with no bounds check. On the unencrypted path that length byte is unauthenticated (attacker- or noise-controlled), so a corrupted RF frame can declare up to 255 bytes and overrun optData while parsing an incoming frame. The sibling FCP_Get_OptData_Length() already validates exactly this condition and returns ERR_LENGTH_MISMATCH; FCP_Get_OptData() did not.

Fix

Add the same length check before the memcpy, returning ERR_LENGTH_MISMATCH on mismatch. Valid frames (declared length == bytes present) are unaffected.

Verification

• Host harness compiling the real FOSSA-Comms.cpp against minimal Arduino/AES stubs, built with g++ -fsanitize=address.
• Before: a frame with length byte 200 into an 8-byte buffer triggers an ASan memcpy overflow at FOSSA-Comms.cpp:188.
• After: encrypted and unencrypted encode→decode round-trips still decode correctly; the malformed frame returns ERR_LENGTH_MISMATCH with ASan clean.

Scope note: the encrypted path has an analogous copy behind the AES password check (authenticated, much lower risk); I kept this PR tight to the clearly-exploitable unauthenticated path.