docs: fix TC18.txt citation drift in acf.rs/avtp.rs/can.rs doc comments (issue #164 batch 1)

[SoundMatt]

Summary

Batch 1 of issue #164: fixes TC18.txt citation drift in src/acf.rs, src/avtp.rs, and src/can.rs doc comments (the three worst offenders per the issue's audit). Method mirrors c-RCP #434: for every TC18.txt line N / TC18.txt lines N-M citation (and every Table N/Figure N reference cited alongside one), the cited quote/fact was searched for in the current canonical TC18.txt and the citation updated to its real, individually-verified location — not a uniform line-shift applied blindly. Doc-comment-only change: no behavior change, no .fusa-reqs.json change, no test logic change.

No other files were touched (git diff --stat confirms only src/acf.rs, src/avtp.rs, src/can.rs changed).

Verification

• cargo build: clean.
• cargo test --lib: 1168 passed; 0 failed (unchanged from before this change — doc-comment-only diff).
• cargo fmt --check: clean.
• bash scripts/api-snapshot-check.sh: could not run in this sandbox (rustup/nightly toolchain unavailable), but this diff touches only comments — no item signatures, visibility, or names changed, so the public API surface is unaffected by construction.
• git diff --stat against main: only src/acf.rs, src/avtp.rs, src/can.rs changed.

Before/after table — every citation changed

All "proof" grep commands below were run against the canonical /Users/matt/Coding/SoundMatt/TC18.txt (6095 lines), never against any copy inside the repo.

src/acf.rs

#	Fact quoted	Old citation	New citation	Proof (grep -n '<snippet>' TC18.txt)
1	"event bits evt[2:0] are used to control the usage of the byte_msg_payload"	lines 3672-3673	lines 4071-4072	4071: 3 event bits evt[2:0] are used to control the usage of the byte_msg_payload.
2	"evt[3] is used to request an acknowledge..."	line 3673	line 4072	4072: 4 evt[3] is used to request an acknowledge. I.e. evt[3] = 1 requests acknowledge.
3	"event bits evt[2:0]..." (Evt::sub_opcode field doc)	line 3672	line 4071	(same as #1)
4	"if op = 0 this is read_size, else segment_num" (Table 4)	line 1163	line 1235	1235: read_size/segment_num if op = 0 this is read_size, else segment_num
5	"op = 0b .../ op = 1b ..." meaning (Table 4)	lines 1160-1161	lines 1229-1230	1229: op 0b – indicates that the sender... / 1230: 1b – indicates that the sender of this request does not expect a response with data
6	"evt[3:0] = 0xF - acknowledge"	line 1876	line 2255	2255: evt[3:0] = 0xF - acknowledge
7	"rsv 00b" (Table 4)	line 1153	line 1223	1223: rsv 00b (first occurrence, within Table 4's field block starting line 1219)
8	"rsv 00b" (response table)	line 1867	line 2248	2248: rsv 00b (within Table 17's field block)
9	"acf_msg_type 0x0E (ABB message)"	line 1149	line 1219	1219: acf_msg_type 0x0E (ABB message)
10	"0x0E - ABB message without message_timestamp"	line 1863	line 2242	2242: acf_msg_type 0x0E - ABB message without message_timestamp
11	"0x0D - GBB message, with message_timestamp"	line 1863	line 2243	2243: 0x0D - GBB message, with message_timestamp
12	"In case responses include a timestamp, they are in ACF_GBB format, else in ACF_ABB format."	line 1859	line 2239	2239: 7 In case responses include a timestamp, they are in ACF_GBB format, else in ACF_ABB format.
13	"When timestamping was not requested, then the ACF_ABB type format without time stamp shall be default..."	line 1963	lines 2340-2341	2340:21 endpoint. When timestamping was not requested, then the ACF_ABB type format without time stamp shall be default for / 2341:22 any data transmitted by the RC Server.
14	§11.3.4 "evt[3:0] < 0x9 and err = 1 the response is an error-response..."	line 1904	line 2300	2300:16 With evt[3:0] < 0x9 and err = 1 the response is an error-response indicating that the execution of the request failed.
15	"message_timestamp = ... mod 2^64" (§11.4.1)	line 1955	line 2331	2331:14 ... message_timestamp = (AS_sec × 10^9 + AS_ns) mod 2^64 ...
16	Table name: response-format table	"Table 15" (12 prose occurrences)	"Table 17"	2266:10 Table 17: Usage of ABB/GBB message for responses (old "Table 15" caption at line 2210 is now a different table, "Usage of GBB message to cancel a single, specific request")
17	Table name: error-codes table	"Table 27" (2 occurrences)	"Table 30"	3844: 9 Table 30: Error codes in responses (current "Table 27" is now "Responder QUEUE_config", unrelated content)
18	Table name: per-endpoint evt-field table (mis-cited, not just drifted)	"Table 30" (1 occurrence, evt_bits_2_to_0... test)	"Table 33"	4116: 7 Table 33: EP specific usage of evt-field — this comment always meant the evt[2:0] endpoint-behavior table, which was never "Table 30" under any numbering; "Table 30" is the unrelated error-codes table (see row 17)

src/avtp.rs

#	Fact quoted	Old citation	New citation	Proof
1	NTSCF header "shall be used for RCP requests which shall be executed as soon as possible or under request specific conditions as well as for responses and acknowledge" (§11.1)	line 1062	lines 1130-1131	1130:10 The corresponding NTSCF header in version 0 shall be used for RCP requests which shall be executed as soon as / 1131:11 possible or under request specific conditions as well as for responses and acknowledge.
2	"The RC Server always uses NTSCF header" (§11.4.3)	line 1988	line 2354	2354:34 TSCF headers will only be sent by RC Clients, never by the RC Servers. The RC Server always uses NTSCF header and only
3	"If neither a gPTP nor an IEEE1722 frame is found the received frame shall be discarded." (§12.8.2)	line 3170	line 3567	3567:12 If neither a gPTP nor an IEEE1722 frame is found the received frame shall be discarded.
4	(duplicate of #1/#2 in test comment)	lines 1062 / 1988	lines 1130 / 2354	(same as above)
5	Table name: Discovery request/response tables	"Table 16" / "Table 17"	"Table 18" / "Table 19"	2758:18 Table 18: Discovery request / 2805:15 Table 19: Discovery response

src/can.rs

#	Fact quoted	Old citation	New citation	Proof
1	CAN request/response format, Figure 40 (whole-figure range)	lines 5842-5856	unchanged — already correct	5842: 6 13.7.11.3 CAN EP request handling ... 5856: 9 Figure 40 – can request format
2	CBFF/CEFF/FBFF/FEFF/XL frame-format value table (whole table)	Table 54, line 5447	Table 57, lines 5863-5871	5872:15 Table 57: can frame formats (table body starts line 5863 "CAN frame format / FrameFormat" header row)
3	Table 54/57's Reserved rows 6 and 7	lines 5454 / 5454-5455	lines 5870-5871	5870: Reserved 6 / 5871: reserved 7
4	"Sending remote frames is not supported. In case the CAN ID is 11bits, then it shall be right aligned in the CAN ID field."	line 5471 (x4 occurrences)	line 5887	5887:1 Sending remote frames is not supported. In case the CAN ID is 11bits, then it shall be right aligned in the CAN ID field.
5	"For CAN XL this can be up to 2054 bytes (2048 + 6, see below)"	line 5443 (x3)	line 5859	5859:11 The on-wire example shows "CAN data" with only 3 bytes. For CAN XL this can be up to 2054 bytes (2048 + 6, see below),
6	"CAN data" field includes 6 additional bytes (RRS/SDT/VCID/AF) for CAN XL	line 5472 (x3)	line 5888	5888:2 The "CAN data" field includes the additional data (RRS, SDT, VCID, AF (in total 6 bytes)- see ISO11898-1) needed for CAN
7	Segmentation via ms/segment_num	line 5444	line 5860	5860:12 which requires segmentation, which is supported by the fields "ms" and "segment_num".
8	Six CAN functional-config capabilities enumerated	lines 5351-5356	lines 5767-5772	5767:10 • Bit rate settings for arbitration phase valid for CAN XL, CAN FD / CAN FD light and Classical CAN ... 5772:15 • usage of new PL (YES|NO) for CAN XL
9	CAN functional-config register layout (bit-time regs 1-3, TDCC, EP/FIFO status, acceptance/receive filters 1-4)	Table 53, lines 5363-5419	Table 56, lines 5795-5834	5836: 2 Table 56: can functional configuration; body from 5795: 0x000C CAN bit time register 1 ... to 5834: 0x003C receive filter 4 ...
10	Request-payload bit layout carrying FrameFormat + CAN ID in the first 32-bit word	"Figure 39", line 5428	Figure 40, line 5852	5852: FrameFormat CAN ID — current TC18.txt's own Figure 39 is now "lin request format" (5736:18 Figure 39 – lin request format), not CAN's; the fact this note describes is Figure 40, CAN's own request format (already cited correctly elsewhere in the same file, see row 1)

Not resolved — flagged rather than guessed at

1. Figure 19/20 renumbering + content change (acf.rs, avtp.rs): TC18.txt's own figure captions confirm the ACF_ABB/ACF_GBB "worked example" figures both files describe are now captioned Figure 20 ("ACF_ABB under TSCF header (example)", line 4231) and Figure 21 ("ACF_GBB under NTSCF header (example)", line ~4256) rather than Figure 19/20. The ACF_ABB example's numbers (6 payload + 2 pad + 4-byte CRC32 = 20 bytes = 5 quadlets) are confirmed unchanged. The ACF_GBB example's own byte breakdown changed content, not just its number: it now shows 5 payload + 3 pad bytes (same 4-byte CRC32, same 28-byte/7-quadlet/acf_msg_length = 0x07 total) rather than the 7 payload + 1 pad this crate's comments describe — TC18.txt carries a Commented [BE39]: 051RC4 - text and figure updated marker immediately after this figure, confirming a genuine RC4 content revision, not just a renumbering artifact.
   I deliberately left "Figure 19"/"Figure 20" as-is everywhere in both files rather than renumbering, because both files' own test function names — acf.rs's golden-vector stub pointing at crate::e2e::finalize_crc_trailer_matches_figure_19_worked_example/_figure_20_worked_example, and avtp.rs's own ntscf_header_matches_figure_20_worked_example/tscf_header_matches_figure_19_worked_example — still embed the old numbers. Renumbering the prose alone would desync it from those identifiers across files (crate::e2e is out of scope for this batch). I added explanatory notes in both files' doc comments recording this finding in full so it isn't silently lost; a follow-up that renames the affected test functions (in acf.rs, avtp.rs, and crate::e2e) together should also renumber the prose.
2. Test/const function names embedding stale table numbers: acf.rs's table_15_discriminants_differ_by_exactly_the_message_timestamp, and can.rs's frame_format_wire_values_match_tc18_table_54/frame_format_from_u8_rejects_table_54_reserved_rows_6_and_7, still carry their original (now-stale) table numbers in their Rust identifiers. Their doc comments/bodies are fixed to the correct current table numbers (Table 17, Table 57); the identifiers themselves are left untouched since renaming a test function is outside the scope of a citation-only fix (and isn't itself a "citation"). Both are flagged with inline notes at their point of use.

Scope confirmation

• Only src/acf.rs, src/avtp.rs, src/can.rs touched — no discovery.rs, e2e.rs, gpio.rs, i2c.rs, lifecycle.rs, lin.rs, mdio.rs, pwm.rs, request.rs, timestamp.rs, or .fusa-reqs.json changes (those are later batches / already fixed in fix: correct REQ-CMP-003/REQ-LIN-008 .fusa-reqs.json citation gaps #163).
• Not merged — left open for independent review per the task.

Closes part of #164 (batch 1 of remaining files).