NETWORK_REPORT: correct 64.3 -- the Ethernet Port Error banner is a clean-boot condition

The terminal shows 'Ethernet Port Error - 24' after a clean boot while its port
works, so it is the firmware's own Ethernet self-test result (which also fails
in MAME per LANCE_LOOPBACK_REPORT), not damage from the payload.

Consequences: the banner is not evidence about the takeover, and the 'needs a
power cycle' claim now rests only on the runs that crashed; for the REST=0x0073
build the network was never checked after the run.

harness/mame/NETWORK_REPORT.md

@@ -4349,3 +4349,34 @@ layout: the text row `REST` sits at y 846-867 and the box at y 850-874, so they
 overlap. The text panel already reports `OK YES/NO`, so both indicator boxes
 (`ok` at x 120 and TX-done at x 160) have been removed. Cosmetic only — the
 values in 64.1/64.2 are unaffected.
+
+## 65. Correction: "Ethernet Port Error - 24" is a clean-boot condition
+
+Section 64.3 used the banner `Ethernet Port Error - 24` on the screen behind the
+panel as evidence that the firmware's network driver had been left broken by the
+payload. **That is wrong**: the terminal shows this banner after a **clean boot**
+as well, while its Ethernet port works normally (the unit answers ping and the
+rdebug service on port 771).
+
+So the banner is the firmware's own **Ethernet self-test result**, not a runtime
+fault. It is worth noting for the LANCE work that this matches the emulator: the
+firmware's `C - LANCE TEST` also fails in MAME (`LANCE_LOOPBACK_REPORT.md`, the
+`RMD1_FRAM` mismatch), while ordinary traffic passes. In other words the
+self-test's expectation is not met by this hardware either — pre-existing, and
+unrelated to the takeover payload.
+
+### 65.1 What that changes
+
+* The banner is **not** evidence about the payload. Section 64.3's conclusion
+  ("the driver noticed the chip disappear and marked the port failed") is
+  withdrawn.
+* The claim "a takeover run costs a power cycle" therefore rests only on the
+  runs that **crashed** (the `0x23CC50` write and the marker/`.text` overlap).
+  For the current build — the one that produced `REST = 0x0073` — the unit was
+  never pinged after the run, so **end-to-end recovery is unverified**, not
+  disproved.
+* The check is one command, after a successful (non-crashing) run:
+
+```sh
+ping -c3 -W2 100.103.100.103
+```