docs: scope the NAT refutation to WireGuard; IPsec to colo is broken

Correcting an over-generalisation from earlier today. Proving that NAT
does not break Site Magic, I wrote it up as "no addressing outcome
threatens the inter-site tunnel." That is wrong: the fleet has two
inter-site links with opposite NAT behaviour.

- NH3<->ESH is Site Magic, i.e. WireGuard. It survives arbitrary NAT,
  proven live on RFC1918 double-NAT (192.168.200.111) with nh3-dev and
  nh3-docker reachable at ~40ms. It dials out to NH3's public edge and
  never needs inbound reachability.

- colo<->ESH is IPsec on the ana-gw FortiGate, and it is broken right
  now under those same conditions. ana-docker, pfi-pve and pbs-ana all
  fail from esh-pve-nas, and traceroute shows packets for 10.250.x
  leaving the UDM to the 5G modem and then wandering the carrier network
  before dying -- not encapsulated at all, so no SA is up and the
  traffic falls through to the default route. Site-to-site IPsec pins a
  peer IP and ESH no longer has a routable one.

So the IPv6 work keeps its justification, but on the IPsec link
specifically rather than on the tunnels generally. Operator caught the
over-generalisation.

Adds lesson 8 -- a result proven for one protocol does not transfer to
another -- and corrects the superseded-claims row rather than replacing
it, since the original claim was half right and the halves are the
point. Also records my own over-broad claim as its own superseded row.

docs/pfi/ops-lessons-playbook.md

@@ -203,8 +203,30 @@ that moves *all* site traffic rather than just the tunnel.
 
 ---
 
+## 8. A result proven for one protocol does not transfer to another
+
+**Rule:** when a test clears a risk, state **which mechanism** it cleared it for,
+and check whether every affected system shares that mechanism.
+
+**Why:** proving that NAT does not break **Site Magic** (WireGuard, outbound-dialed
+to a public peer) I wrote up as "no addressing outcome threatens the inter-site
+tunnel." But the fleet has *two* inter-site links with opposite NAT behaviour, and
+the other one — **IPsec** to the colo FortiGate — was **already broken at that
+exact moment**, traffic leaking unencapsulated to the carrier. The operator caught
+it; the test I had just run would have caught it too, had I run it against both
+links instead of one.
+
+**How to apply:** ask what property made the test pass — here, "outbound-initiated,
+peer needs no inbound reachability" — and then ask which systems *lack* it. IPsec
+site-to-site pins a peer IP and expects a routable address; WireGuard does not.
+Same NAT, opposite outcome. Enumerate the affected set before generalising, and
+name the mechanism in the conclusion so the scope is visible to the next reader.
+
+---
+
 ## Superseded claims
 
 | date | claim | correction |
 |---|---|---|
-| 2026-08-18 | "ESH behind CGNAT will break Site Magic (NH3↔ESH) on IPv4, so IPv6 is the escape hatch" | **False.** Tested live during the fiber cutover: ESH on RFC1918 double-NAT (`192.168.200.111`), tunnel held with full reachability to all ESH hosts. Site Magic is WireGuard dialing out to NH3's public edge, so the NAT'd side never needs an inbound path. IPv6 remains worthwhile but gates nothing. |
+| 2026-08-18 | "ESH behind CGNAT will break the inter-site tunnels, so IPv6 is the escape hatch" | **Half true, and the halves matter.** Tested live on RFC1918 double-NAT (`192.168.200.111`): **Site Magic (NH3↔ESH, WireGuard) HELD** — it dials out to NH3's public edge and never needs inbound reachability. **IPsec (colo↔ESH, ana-gw FortiGate) BROKE** — traceroute showed traffic unencapsulated, leaking to the carrier. IPv6 keeps its justification on the IPsec link only. |
+| 2026-08-18 | *(my own, same day)* "no addressing outcome on the fiber threatens the inter-site tunnel" | **Over-generalised.** I proved it for WireGuard and wrote it as if it covered every link. Operator caught it. See lesson 8. |