NETWORK_REPORT: map the last addressed functions (codec table, dispatchers, re-arm)

Adds rows for the field-codec dispatcher 0x3F660380 / table 0x1E3D80 (8-byte
entries, fn0 at +0, fn1 at byte 4) and its entry-2 pair 0x3F615E00 (convert,
a ntohl-style swap) / 0x3F616090 (compare, the in_pcblookup address-test
idiom) -- the operations are ordinary BSD, the table-driven codec is firmware
specific (no lib/libc/rpc in this tree, no kernel fn-pair table).

Adds 0x3F65A570 and 0x3F6A86D0 as firmware-specific (cmpi 0x72 character-coded
id; not reachable from any EtherType), and the receive re-arm 0x3F9D17E0
(referenced at 0x3F602EC0/0x3F603100) mapped to lereset/ledrinit.

Extends 56.3's coverage statement to match.

harness/mame/NETWORK_REPORT.md

@@ -3911,3 +3911,69 @@ statement is:
 
 That is the honest boundary of the mapping: the protocol stack is 4.4BSD
 lineage, the driver's *deferred* structure is not.
+
+## 57. The remaining addressed functions: codec table, dispatchers, re-arm
+
+Sections 53–56 left four groups out. Each is now either given a counterpart or
+recorded as firmware-specific with the reason.
+
+### 57.1 `0x3F660380` + table `0x1E3D80` — firmware field-codec table
+
+Structure (section 18): index `*(a13+0xC0)` in 0..16, entry = **8 bytes**, `fn0`
+at `+0` and `fn1` at `+0x20` bits (= byte 4); entries 0,1 and 4..15 share one
+pair (`0x3F658570`/`0x3F658650`), entries 2/3 point at `0x3F615E00` /
+`0x3F616090`.
+
+**VT1200-specific, no 4.4BSD counterpart.** Checked for the two things it could
+be: there is no XDR/RPC directory in this tree (`lib/libc/rpc` does not exist)
+and no kernel table of function-pointer pairs indexed by a type code — the only
+dispatch tables 4.4BSD has are `inetsw[]` (already mapped, section 53.1) and
+`struct domain`, neither of which is a per-field codec.
+
+### 57.2 `0x3F615E00` and `0x3F616090` — the convert/compare pair
+
+| ROM | does | nearest 4.4BSD idiom | counterpart? |
+|---|---|---|---|
+| `0x3F615E00` | swaps a 32-bit packet field to host order, stores it, calls `0x3FB2C140` | `ntohl()` / `ntohs()` byte-order macros (`sys/netinet/in.h`) | **idiom only** — in BSD this is a macro inlined at each use, not a dispatch entry |
+| `0x3F616090` | converts two values and compares them, returns 1/0 | `in_pcblookup()`'s address tests, e.g. `if (inp->inp_laddr.s_addr != laddr.s_addr) continue;` (`in_pcb.c:441`) | **idiom only** |
+
+So the *operations* are ordinary BSD operations, but the *table-driven
+{convert, compare} per field type* is the firmware's own design. Neither has a
+line-level counterpart.
+
+### 57.3 `0x3F65A570` and its caller `0x3F6A86D0`
+
+| ROM | what was established | status |
+|---|---|---|
+| `0x3F65A570` | four-case compare chain on a type word; reaches the ARP responder; **not reachable from any EtherType** (section 38); zero executions in every trace | **VT1200-specific dispatcher**, no BSD counterpart |
+| `0x3F6A86D0` | its caller: extracts byte 1 of the argument and tests it against `0x72` (`cmpi 0x72`), i.e. a character-coded protocol id | **VT1200-specific**, no BSD counterpart |
+
+### 57.4 The receive re-arm — `0x3F9D17E0`
+
+Section 30.1 recorded that `0x3F602E00` re-arms the receive buffer, but omitted
+the address. It is `0x3F9D17E0`, installed by the driver as the RX re-arm/post
+routine (it appears as `movi 0x3f9d17e0` at `0x3F602EC0` and `0x3F603100`).
+
+| ROM | 4.4BSD counterpart | evidence |
+|---|---|---|
+| `0x3F9D17E0` | `lereset()` `if_le.c:359` / `ledrinit()` `:337` — the driver's own re-initialisation of the ring | both rebuild the descriptor ring and hand buffers back to the chip; the firmware additionally posts it as a callback, which is the deferred structure noted in 56.2 |
+
+(Note: an earlier review note referred to this as `0x3F9817E0`; the address in
+the ROM is `3F9D17E0`.)
+
+### 57.5 Coverage, final form
+
+The mapping now covers, with a cited line or an explicit firmware-specific
+entry, every function the report gives an address for:
+
+| group | mapped to |
+|---|---|
+| protocol layer | 4.4BSD with quoted lines (53.1, 54, 56.1) |
+| driver | `leinit`/`lereset`/`ledrinit`/`lestart`/`leintr`/`lerint` (53.3, 57.4) |
+| deferred receive / submit / IRQ glue | firmware-specific (56.2) |
+| codec table, protocol-id dispatcher | firmware-specific (57.1–57.3) |
+
+Section 56.3's statement is therefore extended: *the protocol stack is 4.4BSD
+lineage with function-for-function counterparts; the driver maps onto the pmax
+`le*` routines; and the deferred I/O structure, the field-codec table and the
+protocol-id dispatcher are the firmware's own, with no source counterpart.*