canfd : accept to send anonymous messages with payload > 7 bytes

[alex31]

Accept to send anonymous messages with payload length above 7 bytes in canfd mode.
This simplify dynamic allocation node id that can be done in 1 frame instead of 3, and eliminate the risk of garbling when trying to allocate dynamic id to several node at the same time when the whole system is powered up.

[fallenmi]

The transport-specific anonymous payload limit matches the existing one-frame capacity: CAN FD can carry 63 payload bytes plus the tail byte, while classic CAN remains capped at 7 plus the tail. Payload 64 is still rejected, so an anonymous transfer cannot fall into the multi-frame path.

I exercised exact base 601ed35467e0ac38819df17cd7c918de19f62d58 and exact head 3469252a916a913bb6cc2f32fdc0b5589e11266c across the CAN-FD DLC boundaries from 0 through 64. Base accepts through 7; head accepts every sampled length through 63 in exactly one CAN-FD frame and rejects 64; both preserve the classic-CAN rejection at 8. Every accepted frame was fed into a second real libcanard receiver and checked for payload, padding, anonymous source ID, tail flags, and transfer ID. The asserted base/head matrix passed 10/10 under ASan/UBSan.

I also round-tripped the stated dynamic-allocation use case with the canonical DSDL: a full 16-byte unique ID encodes to 18 payload bytes. Base rejects it; head emits one 20-byte CAN-FD frame and decodes the complete allocation request without error, repeated 20/20 under ASan/UBSan. The full CAN-FD-enabled repository suite passes 27/27 on both exact revisions, the classic-only head compile is clean, and git diff --check is clean. I found no blocking issue.

AI disclosure: I used OpenAI Codex to inspect and build the exact revisions, construct and run the boundary and dynamic-allocation round-trip oracles, and draft this review. I verified the commit IDs, source paths, frame bytes, test outputs, and conclusion.