[cpp-RCP-FS-06] Canonical ControlFlags type and Message frame struct are absent #89

Location: include/rcp/acf.hpp — AcfMessageInfo struct (~lines 94-110).

Finding: The RELAY spec's canonical binding for this protocol defines a shared ControlFlags byte type (with named bit constants like an ack flag and a more-segments flag) and a canonical Message frame shape built around it. Neither symbol exists anywhere under include/ in this repo — the individual control bits (evt_ack, op, rsp, err, ms, etc.) are instead spread across separate bool/uint8_t fields directly on AcfMessageInfo. The actual bit encode/decode logic for those fields does appear faithful to the intended bit positions (this isn't a behavioral bug), but the absence of the canonical named type means this C++ port doesn't expose the same shared vocabulary other language ports of this protocol are expected to expose, which weakens cross-port type parity for anything trying to treat ControlFlags/Message as a common interchange shape.

Recommendation: Either add a canonical ControlFlags enum (with the spec's bit values) and a Message-shaped type as a thin view over the existing AcfMessageInfo fields, or explicitly document AcfMessageInfo's field-per-bit layout as this port's sanctioned binding so it's a documented, intentional divergence rather than a silent gap.

Verification: Independently re-read include/rcp/acf.hpp against current HEAD (commit 4b9449a, 2026-07-29) and searched the whole include/ tree for ControlFlags/FlagAck/FlagRead — no matches. Confirmed the individual control bits exist as separate fields on AcfMessageInfo instead. As with the sibling Message.id finding, the canonical-type claim rests on this project's own tracked understanding of the relevant RELAY spec section rather than a fresh re-read of that section's text in this pass.

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