docs: record Serenity DNS and cloudflared retirement

docs/planning/SERENITY_CLEANUP_WAVE_1.md

@@ -73,8 +73,8 @@ From the live Serenity audit:
 Live execution on 2026-05-25 established:
 - `Huntarr` and `omegabrr` were low-risk stale stopped containers and were removed from Serenity
 - the recent non-running `Created` containers (`calibre-web`, `SuggestArr`, `Cleanuparr`, `calibre`, `agregarr`) were not blindly pruned because their metadata was touched recently and they may represent intentional but inactive templates
-- `Unraid-Cloudflared-Tunnel` is not currently dead: it still has a live tunnel token and active Cloudflare edge registrations, so removal requires a separate usage audit first
-- the Serenity Pi-hole HA stack is also not safe to remove blindly yet: `10.5.30.53` is still answering DNS and Serenity is running a backup `keepalived`/Pi-hole stack, so Pi-hole retirement must stay gated on the broader DNS cutover verification
+- `Unraid-Cloudflared-Tunnel` was audited, stopped, and removed after verification showed it was only transport-alive and no current public traffic depended on it
+- the Serenity Pi-hole HA stack (`binhex-official-pihole`, `pihole-serenity`, `unbound-pihole-serenity`, `keepalived-pihole-serenity`) was then stopped and removed after live mixed-host DNS checks confirmed the Technitium path remained healthy without it
 
 ## Wave 1-A: legacy Pi-hole removal
 
@@ -113,10 +113,13 @@ Before removal, verify only these read-only checks:
 
 ### Verification after removal
 
-- Serenity Technitium container remains healthy
-- PD and NOMAD Technitium backup flow still looks normal
-- no client-facing DNS complaints appear
-- no scripts or bookmarks fail because of removed Pi-hole UI endpoints
+- Serenity Technitium container remained healthy
+- mixed-host DNS checks stayed good after removal:
+  - from NOMAD, `10.5.30.8` and `10.5.30.10` still resolved both public and homelab names
+  - from PD, `10.5.30.9` and `10.5.30.10` still resolved both public and homelab names
+- `10.5.30.53` continued answering DNS even after Serenity Pi-hole removal, confirming it is no longer tied to the removed Serenity Pi-hole containers
+- no immediate client-facing DNS regression was observed during the removal window
+- no public regression was observed on sampled hostnames such as `panel.paccoco.com` and `audiobookshelf.paccoco.com`
 
 ## Wave 1-B: stale container pruning
 
@@ -206,6 +209,10 @@ Status after live audit:
 3. keep `/mnt/user/appdata/cloudflared` during a cooling-off window even though it appears empty/unneeded
 4. later, from the Cloudflare side, delete or repoint the stale tunnel config/hostnames if they still exist there
 
+Status:
+- completed on 2026-05-25: `Unraid-Cloudflared-Tunnel` was stopped and removed
+- sampled public checks (`panel.paccoco.com`, `audiobookshelf.paccoco.com`) remained healthy after removal
+
 ## Wave 1-D: DB-backed migration ordering
 
 These apps should not be deleted in wave 1.

docs/planning/SERENITY_DOCKER_AUDIT.md

@@ -67,14 +67,13 @@ These should be treated as cleanup targets unless a specific live dependency is
 
 - `Unraid-Cloudflared-Tunnel`
   - live audit on 2026-05-25 showed a remote-managed Cloudflare Tunnel with stale legacy `192.168.1.x` origins and zero observed proxied requests on the current run
-  - public hostnames in its remote config now appear to be served elsewhere, so it should be removed after a brief stop/remove observation window rather than treated as an active dependency
+  - stopped and removed on 2026-05-25 after post-stop checks showed sampled public hostnames remained healthy without it
 - `binhex-official-pihole`
 - `pihole-serenity`
 - `unbound-pihole-serenity`
 - `keepalived-pihole-serenity`
-  - these are legacy DNS/HA remnants now that Technitium is the active resolver strategy
-  - repo docs now describe the Technitium trio as the active DHCP-advertised internal DNS path
-  - operator confirmed Technitium covers the intended DNS role, so these should be treated as removable at the next cleanup window
+  - these were legacy DNS/HA remnants once Technitium became the intended resolver strategy
+  - mixed-host DNS verification passed during retirement on 2026-05-25, and the Serenity Pi-hole HA stack was then stopped and removed without immediate DNS regression
 - `postgresql15`
 - `MariaDB-Official`
   - both are live, but they are suspicious because current docs position PD as the shared database home

docs/troubleshooting/KNOWN_QUIRKS.md

@@ -70,11 +70,11 @@ Per-service gotchas that aren't bugs but will bite you if you forget them.
 ### Unraid-Cloudflared-Tunnel
 - Older notes called this dead, but live inspection on 2026-05-25 showed active Cloudflare QUIC edge registrations and a configured tunnel token.
 - Follow-up audit showed it is only transport-alive: current-run metrics reported zero proxied requests, its remote-managed ingress config still points at legacy `192.168.1.x` origins, and the listed public hostnames appear to be served elsewhere now.
-- Treat it as removable stale Cloudflare deadwood after a brief stop/remove observation window; preserve appdata during the cooling-off period and clean up Cloudflare-side tunnel config separately.
+- Retired on 2026-05-25: the container was stopped and removed, sampled public hostnames stayed healthy, and Cloudflare-side cleanup can now happen separately from Serenity runtime cleanup.
 
 ### Serenity Wave 1 cleanup guardrails
-- Do not assume `Unraid-Cloudflared-Tunnel` is dead just because it looked obsolete in older notes; live inspection on 2026-05-25 showed active Cloudflare tunnel registrations, so audit usage before removal.
-- Do not remove Serenity's Pi-hole HA containers blindly while `10.5.30.53` still answers DNS; verify the full Technitium cutover path first.
+- `Unraid-Cloudflared-Tunnel` has already been retired from Serenity runtime; any remaining cleanup is Cloudflare-side control-plane cleanup, not local container cleanup.
+- Serenity's legacy Pi-hole HA containers were retired on 2026-05-25 after mixed-host DNS verification; if future DNS issues appear, investigate the surviving Technitium/other-resolver path rather than trying to resurrect those old Pi-hole containers by default.
 - Recent `Created` containers on Unraid may represent intentionally retained templates rather than stale debris; distinguish them from long-dead exited containers before pruning.
 
 ### Serenity Newt / Pangolin stale health-check IP drift