NETWORK_REPORT: osboot 3 of 3 on the unit; scripted hand-back is 7 s load + 40 s restart

harness/mame/NETWORK_REPORT.md

@@ -4871,9 +4871,29 @@ A second screenshot shows the Terminal Manager live again — `08-00-2B-16-4B-5A
 `100.103.100.103`, `LAT_08002B164B5A`, 4 MB free, and the boot-time
 `Attempting to set font path. / Using local fonts.` messages.
 
-**2 of 2, both 40 s**, from two different starting states. That is enough to
-treat `osboot` as the hand-back, and it is the only command in this report whose
-success rate is above zero on the real machine.
+### 73.3.1 Third run, scripted: 3 of 3, 40 s again
+
+The automated hand-back (`harness/udpstream/test-osboot.sh`) was then run end to
+end on the unit:
+
+```
+[*] listening for the announce on enp197s0f3u1
+[*] loading udpstream/build/lance_cmd.coff onto 100.103.100.103
+announce from 08:00:2b:16:4b:5a after 7.2 s
+payload: RXF=1 bytes=60 cmds=1 ... txfull=0
+[*] handing back with osboot
+osboot: control -> bit 0x3f5788c0, status 0
+[+] back after 40s
+```
+
+**3 of 3, 40 s every time**, and this run also measured the load: the payload is
+live **7.2 s** after the script starts, so the hand-back costs 7 s of load plus
+40 s of OS restart.  The old test harness slept a fixed 45 s after starting the
+loader, which is why the operator watched a payload sit idle for ~38 s — the
+sleep, not the machine.
+
+`osboot` is now the documented hand-back, and it is the only command in this
+report whose success rate on the real machine is above zero.
 
 ### 73.4 The payload announces itself, so the host does not sleep
 
@@ -4896,4 +4916,5 @@ moment its RX ring is armed:
 
 `vtcmd.py wait` listens for it, and `test-osboot.sh` ties the whole hand-back
 together with **no sleep**: listen, load, wait for the announce, `stats`,
-`osboot`, wait for `:771`.
+`osboot`, wait for `:771`.  Measured on the unit: announce at 7.2 s, `:771` back
+40 s after the hand-back (section 73.3.1).