docs(esh): record the held DAC decision — forced 10G stays until the weekend cable swap

Operator is keeping the override rather than reverting: he has a replacement
cable and will run it at the weekend. Recorded as a held position so a later
session does not revert it as an oversight or re-run the diagnosis.

Also corrects a claim this runbook made an hour earlier. I wrote that the
zero-error 1G link ruled out a marginal cable. It did not — it only proved the
cable was clean at 1G. The two-hour soak shows errors climbing monotonically at
10G (200 to 221 rx, ~1 per 23 MB) plus one self-recovering link drop, so the
autoneg fallback had a real basis and the fix is the cable, not the config.

docs/runbooks/esh-media-dac-10g.md

@@ -1,7 +1,22 @@
 # ESH-Media 10G uplink — the DAC that negotiated 1G, and the fix
 
-Fixed 2026-09-04. The link now runs at 10G by an explicit rate override on the
-UDM side. **Read the pinned-port warning below before touching that port.**
+2026-09-04. The link runs at 10G by an explicit rate override on the UDM side.
+**Read the pinned-port warning below before touching that port.**
+
+> ## ⚠ CURRENT STATE: forced 10G, KNOWN MARGINAL, held deliberately
+>
+> **Operator decision 2026-09-04: leave the override in place.** He has a
+> replacement cable and will fish it through the garage at the weekend. Do not
+> revert it and do not re-diagnose it — this is a held position, not an
+> oversight.
+>
+> The link is **not clean at 10G**: errors accumulate steadily (200 → 221 rx over
+> 42 min, ~1 per 23 MB, roughly one bad frame in 15,000) and it dropped once, at
+> 10:12, recovering on its own. Nothing rebooted. TCP rides over it; expect
+> retransmits and jitter rather than visible corruption.
+>
+> When the cable is swapped: **remove the override** and let autoneg work. A
+> properly-coded DAC negotiates 10G on its own — that is the whole point.
 
     link      ESH-Media SFP+1 (port 11)  <--DAC-->  ESH-UDMPM SFP+2 (port 11, eth10)
     cable     OEM "SFP-H10GB-CU3M", serial CSC200803000004, 3 m passive twinax
@@ -83,10 +98,20 @@ The switch end logged ~200 rx / ~196 tx errors **during the renegotiation
 window** and none afterwards. Counters were flat across the following two
 minutes while real traffic flowed, and a longer soak was run to confirm.
 
-⚠ **This is the number to watch.** A forced rate on a cable the platform did not
-want to run at 10G is exactly the case that can be marginal. Errors climbing
-steadily — rather than a one-off burst at link-up — mean the cable really cannot
-carry 10G cleanly and the override should be reverted and the cable replaced.
+⚠ **This is the number to watch, and it went the wrong way.** A two-hour soak
+showed the errors do **not** plateau: 200 → 221 rx and 196 → 199 tx over 42
+minutes, monotonic, about 1 rx error per 23.2 MB — plus one link drop at 10:12
+that recovered on its own with no device reboot.
+
+⚠⚠ **So an earlier claim in this runbook's own history was wrong and is
+corrected here: a clean, zero-error link at 1G does NOT rule out a marginal
+cable.** It only proves the cable is clean *at 1G*. Clean at 1G and marginal at
+10G is exactly what a 3 m OEM twinax with unparseable compliance codes turns out
+to be — which means the platform's autoneg fallback was protecting something
+real, not being fussy about vendor coding. For comparison, the TP-Link
+TL-SM5220 on the adjacent UDM port carries 780 GB with 4 errors.
+
+The fix is the cable, not the configuration.
 
 ## Rollback