NETWORK_REPORT: correct 54.4's coverage claim in place

It said every addressed function has a BSD counterpart. The protocol layer
does; the deferred receive/submit path and the interrupt dispatcher are
firmware glue with no 4.4BSD equivalent (section 56).

harness/mame/NETWORK_REPORT.md

@@ -3780,13 +3780,19 @@ separately and ESTABLISHED family grouped also matches `:872` vs `:897`.
 
 ### 54.4 Coverage
 
-With 53 and 54, every function the report gives an address for now has a BSD
-counterpart: driver (`leinit`/`lereset`/`ledrinit`/`lestart`/`leintr`/`lerint`),
+With 53 and 54 the **protocol-layer** functions all have a BSD counterpart:
 IP (`ipintr`, `inetsw[ip_protox[]]`, `ip_output`), ICMP (`icmp_input`,
 `icmp_reflect`, `icmp_send`), TCP (`tcp_input`, `tcp_dooptions`, `tcp_mss`),
 UDP (`udp_input`, `udp_output`), raw IP (`rip_input`), ARP (`in_arpinput`,
 `arpresolve`, `arplookup`, `arprequest`) and the PCB lookup (`in_pcblookup`).
 
+Driver functions map to `leinit`/`lereset`/`ledrinit`/`lestart`/`leintr`/`lerint`,
+**but not every addressed function is driver code**: the deferred receive/submit
+path and the interrupt dispatcher are the firmware's own glue and have no 4.4BSD
+counterpart. Section 56 completes the list, quotes the identifiers that were
+missing here, and replaces an earlier over-broad claim ("every function the
+report gives an address for") with that accurate statement.
+
 ## 55. The PCB field order proves the mapping at struct level
 
 Section 31.1 gave the binding entry's fields from disassembly alone. The BSD