nuc: scrub clean — 0B repaired, no known data errors, no dropouts

The metadata/file errors were artefacts of the interrupted writes, not
corruption. The 2.5h scrub doubled as a soak test of the new cable.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

nuc/usb4t-dropouts.md

@@ -45,15 +45,23 @@ zpool scrub usb4t          # validate the whole pool
 If `clear` hangs: `zpool export usb4t && zpool import usb4t`, reboot as
 a last resort. Datasets remount by themselves once the pool resumes.
 
-Damage from the 2026-08-28 incident: two pool-metadata objects
-(`<metadata>:<0x0>`, `<metadata>:<0x3d>`) and one file —
-`/srv/media/videos/David Gilmour - Live In Gdansk (2008)/…D3.ISO`
-(re-rippable). Nothing in the backup datasets.
+Damage from the 2026-08-28 incident, as first reported: two
+pool-metadata objects (`<metadata>:<0x0>`, `<metadata>:<0x3d>`) and
+one media file. **The scrub cleared all of it** — 1.08 T verified in
+2 h 29 m, `0 B repaired, 0 errors`, and the error list is now
+`No known data errors`. Those entries were artefacts of the
+interrupted writes, not real corruption; nothing had to be restored.
+(One CKSUM count remains on the vdev — a single checksum ZFS fixed
+from its own redundant metadata copy.)
+
+The scrub also served as a 2.5-hour soak test of the new cable:
+**zero USB disconnects** during it.
 
 ## Fixes, in order
 
 1. **Cable + port** — short quality cable, straight into a rear USB-3
-   port, no hub *(done 2026-08-28)*.
+   port, no hub *(done 2026-08-28; survived a 2.5 h scrub with zero
+   disconnects — watch for a week before concluding)*.
 2. **Disable USB autosuspend** so power management cannot drop the
    device: `usbcore.autosuspend=-1` on the kernel command line, or
    per-device `echo on > /sys/bus/usb/devices/<dev>/power/control`.