[cpp-RCP-02] ISELED response models wrong field widths and an invented CRC-8 instead of the native 4-bit CRC #71

Location: include/rcp/iseled.hpp — IseledResponse struct and compute_native_crc8/kNativeCrcPoly (~lines 59-85).

Finding: The governing specification's ISELED response shape is a 12-bit address plus 12-bit data plus an optional, narrow (4-bit) native ISELED CRC trailer. The implementation instead models the response address as a full uint16_t, the data as an open-ended std::vector<uint8_t>, and the optional CRC as a full byte computed with an 8-bit CRC (polynomial 0x07) that the header's own comments say is this implementation's own invented choice, not sourced from the ISELED standard. So both the field widths and the CRC width/algorithm diverge from what a real ISELED-network response actually carries, and the invented 8-bit CRC would not interoperate with real ISELED hardware or another conformant implementation even if the width mismatch were otherwise tolerated.

Recommendation: Model the address and data fields at their real 12-bit width (e.g. packed into the existing byte layout rather than left as a 16-bit int and open vector), and either drop the native-CRC field entirely (since the governing RCP spec doesn't itself define the ISELED CRC algorithm) or replace the invented CRC-8 with the correct 4-bit ISELED-standard trailer. Either way, stop presenting the invented polynomial as if it reflects real ISELED/TC18 behavior.

Verification: Independently re-read include/rcp/iseled.hpp against current HEAD (commit 4b9449a, 2026-07-29), and cross-checked against the governing specification's ISELED endpoint section, which documents the response as 12-bit address + 12-bit data + optional CRC field. Confirmed the code's uint16_t address, open-ended data vector, and 8-bit native_crc/CRC-8 implementation all diverge from that shape.

Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.