CMD_SEND_RAW_DATA treats packed path descriptor as byte count

[D4ni3l3Q]

CMD_SEND_RAW_DATA (25) in examples/companion_radio/MyMesh.cpp seems to still treat path_len as the number of path bytes:

int8_t path_len = cmd_frame[i++];

if (path_len >= 0 && i + path_len + 4 <= len) {
    uint8_t *path = &cmd_frame[i];
    i += path_len;
    ...
    sendDirect(pkt, path, path_len);
}

With the current path format though, this byte is a packed descriptor: the lower 6 bits contain the hash count and the upper 2 bits encode the hash size. The number of encoded path bytes can therefore differ from the descriptor value.

For example, 0x41 describes one 2-byte hash, but CMD 25 treats it as 65 path bytes and fails the bounds check.

There also seems to be a signedness issue: the descriptor is stored in an int8_t, so valid 3-byte-hash descriptors in the 0x80–0xBF range become negative and are rejected.

CMD_SEND_CHANNEL_DATA (62), in the same file, already handles this representation differently: it keeps the descriptor as a uint8_t, validates it with Packet::isValidPathLen(), and uses the packed descriptor to determine how many path bytes to consume.

I think CMD 25 should do the same: treat the field as a packed descriptor, advance over the actual encoded path byte count, and still pass the original descriptor to sendDirect().