docs: record Serenity cloudflared audit

docs/planning/SERENITY_CLEANUP_WAVE_1.md

@@ -168,6 +168,25 @@ Before deleting each one:
 
 - It is already documented in repo docs as dead/stale.
 - Pangolin/Newt is the active exposure pattern now.
+- Live audit on 2026-05-25 showed the container is a remote-managed Cloudflare Tunnel carrying a stale legacy config, not an active Serenity service path.
+
+### Live audit findings (2026-05-25)
+
+- `Unraid-Cloudflared-Tunnel` is healthy at the transport layer (`/ready` reported 4 ready connections), but metrics showed `cloudflared_tunnel_total_requests 0` and `cloudflared_tunnel_request_errors 0` for the current run.
+- Startup logs exposed the remote-managed ingress set as legacy hostnames pointed at old `192.168.1.x` origins:
+  - `wazuh.paccoco.com` -> `https://192.168.1.102`
+  - `remotely.paccoco.com` -> `http://192.168.1.180:5001`
+  - `hp.paccoco.com` -> `http://192.168.1.180:3000`
+  - `octoprint.paccoco.com` -> `http://192.168.1.52`
+  - `audiobookshelf.paccoco.com` -> `http://192.168.1.5:13378`
+  - `spoolman.paccoco.com` -> `http://192.168.1.202:7912`
+  - `node1.paccoco.com` -> `https://192.168.1.189:8080`
+  - `hp2.paccoco.com` -> `http://192.168.1.224:3000`
+  - `panel.paccoco.com` -> `https://192.168.1.189`
+  - `nextcloud.paccoco.com` -> `http://192.168.1.5:11000`
+- The tunnel has no local config files under `/mnt/user/appdata/cloudflared`; it is driven entirely by Cloudflare-side config plus a token.
+- Public checks for those hostnames currently resolve to `172.245.79.139` and return either live responses or front-door 404s without producing any new tunnel traffic, indicating the present public path is elsewhere and not traversing this Serenity container.
+- Repo/docs no longer identify this tunnel as an intended live exposure path; the only repeated modern exposure requirement in Serenity docs is the local Pangolin/Newt lane.
 
 ### Preconditions
 
@@ -175,12 +194,17 @@ Before deleting each one:
 2. verify no local notes still treat it as the active exposure path
 3. verify Newt-based routes are the real live path
 
-### Action
+Status after live audit:
+- (1) satisfied enough for container retirement: no observed current public traffic is reaching this tunnel
+- (2) satisfied: local docs treat it as stale legacy deadwood, not the intended active path
+- (3) satisfied for Serenity-hosted apps: Pangolin/Newt remains the intentionally preserved exposure path
 
-- stop container
-- observe briefly for any missed dependency
-- remove container
-- leave appdata for later deletion if not immediately certain
+### Recommended retirement path
+
+1. stop the container and watch briefly for any unexpected complaint or new public breakage
+2. remove the container
+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
 
 ## Wave 1-D: DB-backed migration ordering
 

docs/planning/SERENITY_DOCKER_AUDIT.md

@@ -66,8 +66,8 @@ These are live today, but they are not good long-term reasons to keep Serenity a
 These should be treated as cleanup targets unless a specific live dependency is rediscovered.
 
 - `Unraid-Cloudflared-Tunnel`
-  - already documented as dead/stale in repo docs
-  - should be removed after one final dependency check
+  - 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
 - `binhex-official-pihole`
 - `pihole-serenity`
 - `unbound-pihole-serenity`

docs/troubleshooting/KNOWN_QUIRKS.md

@@ -69,7 +69,8 @@ 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.
-- Treat it as a live service pending usage audit, not a safe blind-removal candidate.
+- 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.
 
 ### 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.