docs(ipv6): correct the NH3 delegation finding — eight /64s, not one

The note concluded AT&T delegates a single /64 and that reading the
address pattern as a /60 was a mistake. A later finding in the same
session overturned that by reading the BGW's own statistics page, and
that correction was never written down; it survived only in the
transcript and surfaced again while assessing whether more prefixes
could be claimed.

The gateway holds the /60 and rations it, keeping half for itself and
delegating the top eight /64s one at a time. Both observations agree:
a prefix-id only carves within a delegation already held, so the
earlier test could not have moved a lone /64 regardless. The limit is
that UniFi solicits once, which makes the requester the ceiling rather
than the carrier.

persistent-memory.d/2026-08-17-fleet-ipv6-mesh.md

@@ -127,3 +127,41 @@ Cloudflare DNS-edit token, so this is self-serve.
   WireGuard holds keys in kernel memory, so no restart was needed. The parent
   `/etc/wireguard` was already 700, which capped the real exposure to root-capable
   contexts inside the LXC — but the modes were still wrong.
+
+---
+
+## CORRECTION (recorded 2026-08-24): "AT&T delegates exactly ONE /64" is the
+## per-REQUEST truth, not the total — eight /64s exist and are unclaimed
+
+The section above concludes AT&T hands out a single `/64` and that the
+`c110`/`c11f` pattern reading as a `/60` was a misread. **That conclusion was
+itself superseded later in the same session, and the correction never made it
+into memory** — it survived only in the session transcript, and was recovered
+2026-08-24 while assessing a proposal to grab more prefixes.
+
+Reading the **BGW's own LAN statistics page** gave the whole picture:
+
+```
+BGW WAN v6   2001:506:70b2:8958::1      <- AT&T's transit prefix
+BGW LAN v6   2600:1700:b25:c110::/64    <- the BGW keeps this for itself
+Delegated    2600:1700:b25:c11f::/64    <- what the UDM got
+```
+
+**The BGW holds the `/60` and rations it**, keeping `c110`–`c117` for itself and
+delegating from the top down — the UDM got `c11f`, the last one. So
+`c118`–`c11f` are **eight delegatable /64s that genuinely exist and are yours**,
+sitting unclaimed.
+
+Both observations are compatible, which is why the first one looked conclusive:
+the prefix-ID test only carves *within* a delegation already held, so a UDM
+holding one `/64` cannot move it no matter what prefix-ID you set. The BGW
+issues **one `/64` per IA_PD request**, and **UniFi solicits exactly once**.
+
+**Consequence — the ceiling is the requester, not the carrier.** More prefixes
+need more IA_PD requests (multiple IAIDs, or multiple client DUIDs), which the
+UDM will not do. That is what makes a separate DHCPv6-PD client viable, and it
+is why "ask AT&T for a bigger delegation" may be aimed at the wrong party: this
+looks like BGW rationing rather than a provisioning-profile limit.
+
+Live state at correction time: `wan_dhcpv6_pd_size: 64`, `wan1 v6
+2600:1700:b25:c110::48`, all 5 NH3 LANs still `ipv6_interface_type: none`.