docs: record Serenity Newt and wave 1 verification

docs/planning/SERENITY_CLEANUP_WAVE_1.md

@@ -302,3 +302,29 @@ After wave 1, Serenity should still be alive for the workloads that currently ju
 - stale created/exited clutter gone
 
 That leaves a cleaner host and a safer runway for the later PD storage cutover and full Serenity retirement.
+
+## Wave 1 verification results (2026-05-25)
+
+Verified during this planning pass:
+
+- Serenity still has these live containers relevant to wave 1:
+  - `technitium-dns-pilot`
+  - `binhex-official-pihole`
+  - `pihole-serenity`
+  - `unbound-pihole-serenity`
+  - `keepalived-pihole-serenity`
+  - `Newt`
+  - `Unraid-Cloudflared-Tunnel`
+- PD still runs the primary Technitium stack plus its own Pi-hole and Newt lane.
+- From NOMAD, `/etc/resolv.conf` currently lists `10.5.30.8`, `10.5.30.9`, and `10.5.30.10` ahead of external fallback `9.9.9.9`.
+- From NOMAD, `dig` to `10.5.30.8` and `10.5.30.10` succeeded for public DNS resolution; same-host checks to `10.5.30.9` were unreliable, matching the existing macvlan caveat in the docs.
+- `Unraid-Cloudflared-Tunnel` is still running, but repo docs already classify it as dead/stale and its container has `Restart=no`.
+- Serenity `Newt` must not be treated as deadwood: operator confirmed Pangolin tunnels Serenity resources through Serenity's local Newt instead of routing from PD or NOMAD to Serenity resources over the Serenity LAN IP.
+- Live Serenity `Newt` logs still show repeated Pangolin health checks against stale `10.5.1.5` targets (`7474`, `8785`, `8787`, `8788`, `8990`, `8457`, `5690`, `5454`).
+
+Operational implication:
+
+- removing Cloudflared remains low-risk after one final dependency check
+- removing the legacy Pi-hole stack remains appropriate
+- removing Serenity `Newt` is not appropriate during wave 1
+- Pangolin target drift for Serenity-hosted resources should be repaired later by rehoming those resources to the correct Serenity site/local-path model instead of stale literal pre-migration IPs