feat: implement Table 30 Row-2 evt[2:0] validation — CAN (5th endpoint type)

[SoundMatt]

What

Implements TC18 §13.5 Table 33 "Row 2" evt[2:0] request classification for the CAN endpoint type (include/rcp/can.hpp, ep_type 0x0B, §13.7.11) — the 5th of the 8 endpoint types sharing this row ({ADC, PWM_IN, I²C, LIN, CAN, UART, ISELED, MDIO}), following the exact pattern already merged for I2C (#114), ADC (#115), PWM_IN (#116), and LIN (#117).

Row 2's rule (already implemented as the shared rcp::endpoint::evt_row2_kind_of predicate, not reinvented here):

• evt[2:0] == 000b → Plain — ordinary request
• evt[2:0] == 001b–110b → Reserved — reject with EndpointErrc::reserved_evt_row2 (wire error UNSUPPORTED_CMD)
• evt[2:0] == 111b → ConfigWrite — §12.7.1 functional-config write, not yet implemented for any endpoint type in this codebase; reported via a new CanErrc::config_write_not_supported (wire error UNSUPPORTED_CMD)

Changes

• include/rcp/can.hpp: new CanEndpoint::handle_request(uint8_t evt_op, CanDataFrame frame) entry point. Classifies via evt_row2_kind_of first: Plain delegates straight to the existing transmit(std::move(frame)) unchanged; Reserved returns EndpointErrc::reserved_evt_row2 without touching last_tx_; ConfigWrite returns the new CanErrc::config_write_not_supported = 4.
• include/rcp/mock.hpp: CAN wired in as the mock server's 7th representative endpoint at byte_bus_id 7 (GPIO=1, SPI=2, I2C=3, ADC=4, PWM_IN=5, LIN=6, CAN=7) — can() accessor, dispatch_can(), wire_error_code_for mappings for every CanErrc value, endpoint_count/ep_id_mapping updated to seven. REQ-MOCK-001's text now correctly says "seven endpoints" and lists CAN at byte_bus_id 7 (PR feat: implement Table 30 Row-2 evt[2:0] validation — PWM_IN (3rd endpoint type) #116 left this stale for feat: implement Table 30 Row-2 evt[2:0] validation — LIN (4th endpoint type) #117 to fix — checked it here so this PR doesn't repeat that).
• .fusa-reqs.json: REQ-CANEP-008/REQ-CANEP-009 (endpoint-level) and REQ-MOCK-019/REQ-MOCK-020 (mock-dispatch-level) added. Every tc18_master_id independently checked against RELAY's docs/tc18-master-catalog.json: TC18-13.5-001 (Table 33 — its own summary text names CAN explicitly) and TC18-12.7.1-001 (the evt[2:0]=111b config-write clause) — both re-verified against TC18.txt directly rather than trusted blindly. REQ-CANEP-008 tagged severity: "cybersecurity", matching the REQ-ADC-008/REQ-PWM-008/REQ-LINEP-005 precedent, so the cybersecurity-tagged ratio stays at 17% (69/398, integer division) — unchanged from before this PR.
• Tests: tests/test_can.cpp (Plain-delegates, all-6-Reserved-values-rejected, ConfigWrite-rejected-without-touching-state, evt_op masking, and a FrameFormat/CAN-ID independence guard) and tests/test_mock.cpp (same three-way dispatch through mock::Server, plus the pre-RCP_CONFIGURED gating test), mirroring LIN's test shape.

CAN-specific judgment calls (verified directly against TC18.txt)

1. No remote-frame concept, no TriggerRegistry — both were already deliberate omissions in this header (per its own pre-existing comments) and neither was added here. Confirmed directly: TC18.txt states outright "Sending remote frames is not supported" (§13.7.11.3).
2. evt[2:0] is independent of CAN XL's own FrameFormat/frame-format sub-field. Figure 40 (§13.7.11.3) draws the Message Info octet's evt[2:0] bits and the Payload's FrameFormat/CAN ID/CAN data fields as distinct, non-overlapping regions of the request — verified directly in TC18.txt, not assumed. This is exactly the class of mistake this codebase has had to remove before (see rcp/iseled.hpp's and rcp/mdio.hpp's own header comments on previously-invented, non-spec field encodings, and the identical caution LIN's own handle_request comment gives about its compound-wait text). A new test case ("...independent of FrameFormat/CAN-ID...") asserts Reserved/ConfigWrite rejection is identical across Classical/FD/XL.
3. No set_can_response()-shaped test-scripting hook. Unlike I2C/LIN/ADC/PWM_IN, whose Plain requests read back mock-scripted data, CAN's Plain request is a fire-a-frame TX whose outcome is fully and deterministically determined by the request's own frame contents (can::validate_frame) — there's no external "current bus state" for such a hook to script. Documented explicitly in mock.hpp rather than adding a hook that would have nothing to do. dispatch_can() treats the request payload as the frame's raw data bytes (fixed standard id, FrameFormat::Classical) since no CAN wire codec (Figure 40 decode) exists anywhere in this codebase yet — same "not real wire conformance" disclaimer already used throughout mock.hpp.

Mutation test

Temporarily changed the ConfigWrite branch in CanEndpoint::handle_request to call transmit() instead of returning config_write_not_supported, rebuilt, and confirmed exactly 2 test_can assertions + 1 test_mock assertion failed (proving they're load-bearing). Reverted cleanly — git diff showed no stray leftovers, full suite green again afterward.

Verification

• cmake -S . -B build -G Ninja && cmake --build build: clean build, 0 warnings from this change.
• ctest --test-dir build: 100% tests passed, 0 failed (53/53 suites).
• cpfusa check --strict: 0 errors (2 warnings + 1 info, byte-identical output to main before this PR — pre-existing .fusa-evidence.json/HARA005 conditions, not introduced here).
• cpfusa trace: 398/398 (100%) requirements annotated and tested.
• Cybersecurity-tagged ratio: 69/398 = 17% (integer division), unchanged from before this PR.

Not merging myself — opening for review per usual process.